Messaging Platforms

Similarly to the SNs (which also provide messaging features), messaging platforms are effectively integrated products that combine switching modules with high-capacity storage and mechanisms for accessing both the PSTN and Internet databases. Unlike the SNs, however, messaging systems concentrate on near-real-time message manipulation rather than real-time call control. Until very recently, messaging systems had to be integrated within the enterprise with PBXs, as described earlier in this chapter. Some vendors, in fact, sell only software.

New platforms are emerging that are built specifically for unified messaging for both PSTN carriers and enterprises. Platforms start with single boxes that support from 2 to 50 T1 ports; they can be further integrated into distributed systems that include a Web server and a firewall. Single boxes are typically built around the open-standard high-capacity backplane media bus (H.110) and dual 10/100-Mbps LANs. Hot-swappable E1/T1 boards, speech signal processing (SSP) modules, text-to-speech (TTS) conversion modules (multilingual in advanced products), alarm modules (monitoring temperature, voltages, and fans), control processor boards, and storage devices are mounted on the rack. Naturally, a dial-in modem pool is part of the box. You should also expect such a box to have connections to local and remote management consoles. The Web servers (which, in some cases, come on dedicated cards) support the graphical user interface access to visual mailboxes. High-end products support up to 30,000 mailboxes with about 100 sessions, each of which can be either voice or e-mail. To enable the transport of voice messages over the Internet, high-end products also support the Voice Profile for Internet Mail (VPIM) protocol. That way both POP3 and IMAP can be used for retrieving VPIM messages in the same way they are used to retrieve nonvoice e-mail messages. The number of sessions that require text-to-speech conversion varies between 10 and 100. The hardware boxes can, in some cases, be clustered together to build larger systems.

Unified messaging is a 24/7 application (that is, an application that is expected to function 24 hours a day, seven days a week). For this reason, nearly every architecture that implements unified messaging provides fault tolerance mechanisms (achieved through redundancy) for (1) power suppliers, (2) CPUs (in some cases), and (3) storage. Specifically, the redundant array of inexpensive disks (RAID) architecture, in which a single file is broken into blocks of data distributed across an array of disks, seems to be the architecture of choice. In this architecture, one designated extra disk keeps a certain function [exclusive OR (XOR), to be specific] of the blocks on other disks, so that if any disk fails, the blocks it contained will be immediately recovered. In addition to fault tolerance, the architecture provides simultaneous access to all the disks in the array, which speeds up data access by as many times as there are disks in the array and makes the array especially useful for real-time message playing.

An important component of the messaging platform concerns the management of the platform itself. Most messaging products today implement the management component based on SNMP. In addition to local alarm indicators, the SNMP agent for remote alarm monitoring runs as part of the systems software. Advanced products run similar agents for other features of the remote access and diagnostics (RAD) capabilities (such as remote reboot and password administration).

Other functional capabilities of the operations and management software include configuration management for platform administration and subscriber provisioning (through a management console) and support of LDAP API for external provisioning. Call detail records, which are essential for billing, are usually accessible through the File Transfer Protocol (FTP). As always, support of billing is a key differentiating criterion in choosing a particular product. While it is relatively straightforward to offer with the use of IN platform services like call sender with rebound, provision of adequate billing requires much work. Advanced products solve this problem by carefully supporting as many scenarios as possible. For example, to support call sender with rebound, the calls returned from users’ mailboxes must be appropriately logged. High-end products also provide software tool kits that allow you to build not only new services but also new capabilities.

An important product differentiator is the number of supported languages. Advanced products provide multilingual capabilities (up to 22 languages) as well as the support for Telecommunications Device for the Deaf (TDD) (treated as another language). (In some cases, customers who purchase TDD-compatible messaging systems may be entitled to a tax credit under the United States Americans with Disabilities Act.)

In the messaging platforms, the enablers of the voice capabilities are the same as in SNs; similarly, connection to the SS No. 7 network provides full access to IN and wireless signaling protocols. Figure 1 illustrates the entities to which unified messaging platforms are connected. In the PSTN, those entities include both IN SCPs and (typically central office) switches. In the wireless networks, messaging platforms are connected to mobile switching centers (MSCs) and home location registers (HLRs). To support the enterprise (premises-based) telephony, the unified messaging platforms must also maintain connections to PBXs. SNMP-based access to remote operations systems is achieved through the Internet. The connections to access servers are needed for the purposes of IP telephony. Because the unified messaging platforms also function as SCPs, their use of LDAP is very similar to the IN mechanisms for accessing external databases [called service data functions (SDFs)], which store subscriber-specific information. Naturally, these directories are accessed through the Internet.

Figure 1: Messaging platform interconnections.

Messaging platforms provided by one vendor may also work with switches manufactured by different vendors. Interoperability with other vendors’ switches is achieved by carefully supporting multiple SS No. 7 ISUP options. Similarly, some messaging platform products can interwork with like platforms built by other vendors.