The telecom market is starting to pick up. We are seeing a resurgence of interest in adding new network capabilities and services. Most telecom equipment manufacturers and network providers are familiar with the cost benefits of Voice over IP (VoIP). Some are already deploying these systems, as well as looking at ways to exploit the seamless mobility capabilities that these technologies can also provide.
Many audio telephony applications require audio streaming capabilities, whether in a time-division-multiplexing (TDM), packet-, or cell-based environment These applications include voice-archiving and voice-messaging services (VMS), music on hold, announcements, and message broadcast. They connect the user to an endpoint that is a real-time service, yet does not have the acute delay intolerance of a two-way phone conversation. Consequently, the underlying implementation requirements and details differ from what has previously been thought necessary to provide services in a voice environment.
It is possible to implement all of the applications mentioned on a TDM network, but the cost implications may be prohibitive. Music on hold is a good example of where end-to-end delay is not an issue, but where the cost of a providing a bidirectional TDM link to carry a single stream of audio is high, involving 2 x 64kbps links (one in each direction)—a total of 128 kbps. A packet-based solution typically requires a unidirectional link of 8kbps or less.
Similar benefits accrue when the data is flowing in the opposite direction. Take VMS, for instance. A caller leaving a voice message for a recipient is not concerned by an end-to-end delay of 20ms or 1 second.
In addition to lower cost, another benefit to a packet-based solution is flexibility. Once the voice message is in a packet format, it can be converted to a multitude of different formats for forwarding to the recipient. One of the most exciting options is to convert the message to .mp3 before sending it via email. This version of unified messaging gives the recipient options about how and when to receive and review voice messages. The recipients may be sitting in an airport lounge accessing the Internet via broadband or their PDA on the road, listening to the same message via their mobile phone or using the same PDA in wireless mode. Once downloaded to the PDA, the voice message can be managed in exactly the same manner as any other email or SMS message.
The .mp3 file format gained widespread popularity from its use in compressing high-quality audio into a small file that could be easily transported over the Internet. Less well known are .mp3's lower bit-rate options that are ideal for telephony applications. In trials on an in-house telecom network, we tested the use of.mp3 for handling voice messages with coding rates down to 8kps (that is the equivalent of 1kbyte per second). We found that even at this rate, the 64kbps TDM channel was the limiting factor concerning voice quality.
In the last few years, SMS has been one of the largest revenue generators for the mobile network operators. In 2003, over 20bn SMS messages were sent in the UK alone.
A stored voice message has a data requirement of 1kbyte for every second of speech and a typical message lasts around 20 seconds. Therefore, the costs for transmitting a voice message over a packet network is similar to SMS. But VMS is much easier to use and will find acceptance by a far wider audience. It is probable that the volume of VMS will overtake that of SMS.
The use of voice messaging as a supplement to SMS is a great attraction, but other benefits will also attract customers and boost revenue. If voice messaging is the next generation beyond SMS, Push To Talk (PTT) is the mobile phone industry's equivalent to instant messaging. The best bit, though, is the move toward an integrated network where different services can interoperate easily, such as VMS and PTT.
To evaluate the possibilities of VMS, Motorola formed a team to analyse the issues and integrate a complete VMS system. The company built a VMS server from standards-based products and Motorola Embedded Communications Computing Group's ComStruct product line.
COMSTRUCT OVERVIEW The ComStruct family includes hardware and software that can be integrated to build wireless and fixed voice gateway products. Hardware options are optimised for so-called traditional VoIP (that is, The Packet Voice Resource Board or PVRB) and wireless (Wireless Transcoder Resource Board or WTRB) products. Both the PVRB and WTRB product lines are supported by the FACT software framework, a software environment that integrates multi-channel transcoders with network protocols and management software.The ComStruct family can accommodate 'black box' and open solutions. The former is suitable for use in PVRB VoIP applications, and the latter for customised applications or those that encompass custom or proprietary voice or multi-media transcoders.
Control and management of the transcoders is handled via an API that is either host-based (VxWorks) or IP-based. The IP-based solution means that short, simple commands such as NEW, GET, SET, and so on can be used to manage calls over IP, TDM, and ATM networks. With an IP-based solution, the developer can choose the operating system of their host management environment based on network, end customer, or any other preferences. The network manager can create and send packets to the FACT environment that will control the channel processing, and they will receive status messages from FACT that indicate the success or failure of the command and information about any asynchronous events that occur.
The aim of this project was to configure a VoIP-based VMS server that would receive audio streams. Then it would convert those telephony signals into a format that could be stored on a disk system or emailed to a destination.
As shown in Figure 1, the main components of a VMS server are:
- a Network Management Controller to control and manage the VMS operations
- an Announcement Server to stream pre-recorded audio messages across the network
- a Media Gateway (MG) to provide the interface between the TDM and IP networks, and the voice transcoder resource
- a Voice transcoder resource to convert the native IP stream (such as G.711) into the desired compressed audio format (for example, .mp3)
- an SMTP mail server interface to transmit voice messages via email
The VMS server was developed as a single-channel solution that could run on a laptop or the main CPU blade in the chassis. Although the proof of concept was developed as a single channel, the performance of Pentium processors coupled with the low data rates of speech means that a single Pentium processor can handle the many channels necessary for a typical enterprise PBX.
An important issue in today's market is the ability to be flexible when developing an application. No particular aspect of this is more important than being able to port software from one operating system to another. As a result, one of the overriding goals of the project was to use as much open-source software as possible. The choice for server architecture came down to either Linux or Windows XP, meaning that any solution could recompile, without modification, for either target. In the end, the chosen development environment could support many more operating systems, but these two were our primary requirements.
This proof-of-concept showed how easy it is to configure a multi-channel VMS using FACT-server and standard, off-the-shelf components. The system has been run in several configurations of host hardware and operating systems, and on several different networks.
VMS' ease of use exceeded expectations and has surprised everyone who has used the system. Motorola even linked into a corporate network to allow the seamless integration of VMS, Microsoft Exchange Server, Microsoft Outlook, and WiFi-enabled PDAs. The full source code developed for this proof-of-concept system is available from Motorola Embedded Communications Computing Group. It comes with an applications note that describes the full installation and configuration process to rebuild the system.