ip media servers and ims in voicemail and unified messaging VERSION 1.0 | april 2007
CONTENTS introduction.. .........................................................2 motivations for unified messaging.......................2 overview of messaging services...........................4 industry forces.. ....................................................5 Media processing & ip media servers....................7 ims & media servers/mrfps....................................9 um solution architectures................................. 12 radisys media server solutions.......................... 15 conclusions.......................................................... 18 references........................................................... 18
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
Introduction Messaging is a fundamental requirement of modern-day communications, and voicemail, the decades-old service that launched the world’s love affair with messaging, is evolving. Voicemail has been joined by other types of messaging including fax, email, short message service (SMS), multimedia message service (MMS), instant messaging (IM), and videomail, and doubtless more are to come as technology and users’ expectations evolve. Unified Messaging, or UM, integrates these messaging services into a single solution that gives consumers and business users access to all types of messages on any type of terminal, including POTS phones, PCs, mobile phones, and smartphones. There’s no doubt that the need for UM is driven by the strongest trend in telecommunications today: mobility. But “mobile” users expect to access all their messages no matter where they are, no matter what device they’re using, through a unified interface. The richness of UM lets service providers address all these customer expectations and in so doing, increase their revenues. The opportunity that the rapidly growing UM market presents for service providers and their suppliers is large. Alongside the evolution of UM services has been an even more striking technical evolution: the transition from time division multiplexing (TDM) networks to Internet protocol (IP) and voice over Internet protocol (VoIP) networks and the related change from monolithic, proprietary architectures to decomposed, open ones. There is general consensus in the industry that the IP Multimedia Subsystem (IMS)—developed initially by the ThirdGeneration Partnership Project (3GPP)—will eventually be the model architecture for all telecommunications, even if IMS-compliant deployments are still a few years away. This move to IP and IMS for the foundation of all networks, solutions, and equipment will be a great benefit to service providers, reducing their capital and operational outlays. Many legacy TDM-based messaging systems are nearing the end of their lives and must soon be replaced anyway, another factor that accelerates the transition to IP. The IMS architecture is strongly layered and decomposed into well-defined individual functional components. Key among these is the IP media server, also known as the Multimedia Resource Function Processor (MRFP), in IMS. Media servers are the place in the IP core network where all media processing of audio and video streams is done, for example playing and recording files, DTMF detection,
| www.radisys.com
and conference mixing. The IP media server has long been a key part of VoIP and IMS-ready deployments for services such as conferencing, prepaid calling, contact centers, hosted PBX, voicemail, and color ringback tones, and it will see widespread deployment for IP voicemail and UM as well. This white paper examines the different messaging and UM services and markets, the changes taking place in messaging markets and underlying technologies, the role of media servers in messaging services and solutions, and the benefits of RadiSys’ media server products for messaging and UM. The focus will be on audio (voicemail) and video (videomail) features because they are the primary functions with which media servers are involved. Readers will find this white paper useful whether they’re interested in simple voicemail, a full UM solution, or anything in between. The information here is intended for service providers of both consumer and business services, and their solution and equipment vendors, for all types of access including wireline, cable, and wireless. Large enterprises and their vendors will also find this white paper useful.
Motivations for Unified Messaging User Motivations To understand the attraction of unified messaging, consider the situation for the average knowledge worker, who has multiple communication devices and multiple messaging systems, each with its own special access and notification limitations. Each service is an island and it’s generally impossible to send, copy, forward, or reply to messages among services, and there’s no way to message between different voicemail systems. Our typical knowledge worker might have to use and continually monitor: Voicemail: Home voicemail—accessed through any phone, but notifications are delivered only to the home phone Work voicemail—accessed through any phone, but notifications are delivered only to the work phone Mobile phone voicemail—accessed through any phone, but notifications are delivered only to that mobile phone. (Some people carry two mobile phones and will therefore have two mailboxes.)
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
Fax: Home fax—a physical fax machine, usually sharing a voice line Work fax—a physical fax machine, usually in the mail room (which could be far away) Email: Home email—accessed through home Internet connection; mail can also be read (but not sent) through any POP client; can also be accessed through a Web client; no notifications Work email—accessed through PC or Web client, using a VPN if off-network; no notifications Other: SMS and MMS messages—access only through mobile phone or Web-SMS gateway Instant messaging—accessed only through PC or mobile phone Unified messaging seeks to provide users with integrated interfaces to all of these services as well as tools to manage messages, such as find-me/follow-me. UM systems today can’t yet remove all the restrictions listed above, but steady progress is being made as UM offerings get richer and richer.
Service Provider Service providers look to messaging services in general, and unified messaging in particular, as a way to increase their revenues. IP- and IMS-based solutions also help them to lower costs. Revenues Messaging services like voicemail, videomail, and UM bring additional revenues through a number of different means: 1. Messaging is often a billable service, with multiple service levels and packages. 2. Messaging increases call completion rates because calls that would otherwise have failed due to busy or noanswer conditions are now completed. Both the message recording and the subsequent message retrieval increase network utilization.
| www.radisys.com
3. Rich messaging services give users multiple ways to leave a message; they also enable and encourage users to consume more messaging and network resources. 4. Messaging is a key enhanced service that most subscribers use, so it is an excellent starting point for enticing users into additional value-added services. 5. Messaging provides opportunities to sell personalization features to subscribers. This is especially true for videomail, which, although in its early stages, should expand in importance because it provides a much richer user experience than voicemail. When a call is diverted to the videomail service, the caller can be greeted with a personal video clip, a celebrity video message, or a talking cartoon character. This level of personalization appeals to the mobile subscriber base (especially young people), as seen in the popularity of other personalization services such as ringtones, ringback tones, and wallpapers. The branding, advertising, and personalization possibilities for videomail services create new opportunities for service providers. 6. Rich UM service offerings attract and retain customers. A richer UM offering makes users more dependent on it and reduces subscriber churn. Costs IP and IMS present service providers with a much better way to architect and source their networks, services, and equipment. Compared to TDM-based voicemail and UM service platforms, IP- and IMS-based platforms reduce both capital expenditures and operational expenditures. There are two main reasons for this. 1. IP and IMS architectures allow decomposition of service platforms into reusable components with open, standardized interfaces, which can then be sourced independently using a best-of-breed model. 2. IP- and IMS-based service platforms are generally more efficient than TDM platforms in terms of density, rack space, power, management effort, support effort, and spares—all factors that simplify and reduce the expense of ongoing operations. The benefits of IP and IMS are described in more detail below.
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
device type
message type
Wired phone
mobile phone– fax audio/video machine
mobile phone–gui
pc/web
Voicemail
Voicemail (UM)
Voicemail (UM)
—
UM
UM
videomail
—
Videomail (UM)
—
UM
Videomail, UM
fax
UM
UM
Fax (UM)
UM
UM
email
UM
UM
—
Mobile Email (UM)
Email (UM)
sms
—
—
—
SMS
Web-SMS Gateway
mms
—
—
—
MMS
—
im
—
—
—
IM
IM Table 1.
Overview of Messaging Services Messaging Services and UM Unified messaging is defined as the integration of existing messaging capabilities (such as voicemail, email, and fax) into a single mailbox. The term also encompasses new ways of accessing those messages, such as receiving voicemail and faxes through a PC or Web interface. Finally, UM includes new control features such find-me/follow-me. The table below shows the features that a typical UM service brings. Each row is one type of message while the columns are types of terminal devices. Messaging services are the intersection of a message type (row) and terminal type (column), such as voicemail, videomail, email, fax, SMS, MMS, and IM. The combinations labeled “UM” are the additional features found in typical UM services. Those labeled “(UM)” have been around since before the concept of unified messaging was developed, but are considered part of UM offerings. Two sets of features are highlighted in the table. 1. The light blue shading represents “visual” features, such as visual messaging or visual voicemail. The key characteristic of these services is that they allow an email client to create, access, and manage voicemail, videomail, and fax messages. This visual access to all messages is a very important value-add of UM compared to standard voicemail. 2. The tan shading highlights UM features that make direct use of real-time audio, video, and fax streams for creating, accessing, and managing messages. These features are the foundation of UM offerings and are the realm of the IP media server (MRFP), which will be covered below.
| www.radisys.com
The sections below elaborate on the UM messaging services shown in the table and describe the additional value of UM as well as a related service that’s receiving a lot of attention, Unified Communications.
Key Messaging Services Voicemail Voicemail is a familiar and ubiquitous service that allows a call to be diverted to an automated system that records an audio message. The service subscriber can subsequently call in to the system to retrieve (listen to) the audio message. As long as there are unread messages waiting for retrieval, the system will typically provide the subscriber with an audio or visual notification, such as an indicator light on a phone or a stutter dial-tone when the phone goes off-hook. Calls are diverted to voicemail when the caller places a call to the subscriber’s phone number but for some reason the call cannot be terminated on the subscriber’s phone. This could happen because of a busy or noanswer condition or due to call forwarding. Recent enhancements to voicemail allow direct voice messaging, wherein the caller can leave a message for the subscriber without first trying to call their telephone. In some offerings the system will send an SMS to the subscriber notifying them of the waiting message and giving them a link to click on to retrieve the message. This direct voice messaging feature, which is conceptually similar to email or SMS, is becoming very popular and goes by a variety of names, such as audio SMS, voice SMS, SMS voice messaging, and instant voice messaging. Some direct voice messaging services support PSTN phones and the system will repeatedly attempt to deliver a message until a person answers the phone and accepts the message.
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
Videomail Videomail is similar to voicemail except that the messages include video as well as audio. It is typically available on mobile 3G phones and Internet-based video-calling services. Videomail service penetration, while still quite low, will increase as the number of video-capable terminals increases. The diversion and direct-messagecreation types presented above for voicemail also apply to videomail.
types through any and all interface and device types so that users don’t need to check multiple mailboxes through multiple interfaces. Visual messaging is the most important new access method that UM brings, but a UM service may offer access to emails through a phone as well. UM also offers users important new messagemanagement features such as a single phone number, find-me/follow-me, and call filtering. UM systems can send message notifications through a variety of means.
Visual Messaging Visual messaging is an extension to voicemail, videomail, and fax messaging that allows these messages to all be visible from an email client, whether PC-based or Webbased. This very popular feature allows users to manage their audio, video, and fax messages as easily as they manage their email today. Users often find that traditional voicemail systems are difficult and inconvenient to use compared to email. For example, they need to remember obscure command digit sequences (which differ among different vendors’ systems), must navigate messages sequentially, can’t send the messages outside the system, and can’t archive messages. Visual messaging addresses all of these issues and makes voicemail easier to use.
The focus of this white paper is the audio (voicemail) and video (videomail) features of UM, since those are the primary duties of media servers. Most UM systems being deployed today are IP-based and voicemail remains the fundamental and most important service of existing and new UM systems.
Fax through Phones This capability allows a user to manage (but not create or view) fax messages through a telephone. Users can get information on their newly received faxes, manage a set of pre-created faxes, and send, forward, archive, delete, and print faxes—all using a telephone user interface. Although it’s valuable in situations where a phone is the only device available, this feature isn’t as easy to use or as popular as visual messaging for managing faxes. Email Through Phones This feature permits users to create and manage emails through a telephone by using speech processing. Textto-speech (TTS) algorithms read emails to the user and automatic speech recognition (ASR) allows the user to compose and edit new emails. This service is a relatively rare because of the inconvenience of accessing emails sequentially (and very slowly) and because of the technical problems in properly recognizing users’ speech and converting it into proper text for email messages.
Unified Messaging UM integrates of some or all the above along with standard email and fax features. The key feature of UM is its ability to access and manage all message
| www.radisys.com
Unified Communications Unified communications (UC) is distinct from unified messaging (UM) and is receiving a lot of attention in the industry. The term “unified communications” is loosely defined to include unified messaging plus a set of features such as call origination, automated personal assistant, presence management, and conferencing features. Since UM is a subset of UC, this white paper applies to the UM features present in UC offerings. Media servers appear in both UM and UC installations, but the more advanced UC features are beyond the scope of this document.
Industry Forces A number of forces are shaping telecommunications today that affect messaging and unified messaging. This section will deal with three key forces operating at the services, network, and product-platform levels.
Services Evolution—Richer & Richer At the services level, there are strong trends toward greater richness of services and greater availability of services from mobile devices, which are themselves becoming smarter. In messaging and UM, this is causing a movement from voicemail to videomail, from the simple telephone user interfaces of PSTN phones and cell phones to the graphical user interfaces used in visual messaging, and from separate islands of messaging services to unified messaging.
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
APPLICATION
Network Evolution— Decomposition & Layering TDM to IP & IMS The second force is the most important change underway in telecommunications: the shift away from TDM-based architectures, technologies, and products toward IP-based ones. The strong and increasing acceptance of the 3GPP’s IP Multimedia Subsystem (IMS) as the central architecture for telecom networks and services is reinforcing the move to IP. Additionally, many legacy TDM-based systems are nearing their end of life and must soon be replaced, a factor that is accelerating the transition to IP/IMS. IMS, which is layered on top of IP, provides two key benefits over TDM. First, IP and IMS enable a common, or converged, core network architecture for all services, including all access types. No longer are separate networks required for different services or access technologies as they were in the past. This means, for example, that wireless and wireline services, and MOBILITY (FIND ME) TDM- and IP-based devices, can all use the same core SERVICES NODE VOICEMAIL network infrastructure. SERVICE NODE
PREPAID/ Second, IP MSC and IMS architectures are very different from (ANNOUNCEMENTS, RECHARGE TDM architectures, as shown in Figure IVR) SERVICE NODE1 below. By its nature TDM architectures are not very open—for example, NFERENCING only a few interfaces, such as SS7, are standardized—so RVICE NODE solutions tend to be “siloed,” monolithic, and proprietary. SPEECH PORTAL IP and IMS, on the other hand, encourage solutions to be SERVICE NODE layered, decomposed, and open. TDM service platforms are typically LEGACY supplied by a single vendor and contain all TDM NETWORK required to deliver a single service, the network functions such as signaling interfaces, bearer interfaces, call control, service logic, media processing, databases, and storage. The media processing found in TDM systems typically consists of low-density, expensive, and fixed-purpose hardware boards.
The IMS architecture is quite different. IMS is a very decomposed network and service architecture, with a large number of architectural elements all interconnected by standardized interfaces and protocols. These architectural elements are structured into layers— Application, Control, and Transport—where each layer is strongly decoupled from the others, and with each of the bottom two layers (Control and Transport) serving as a reusable infrastructure for the layers above. Adding a new service to the network is therefore simply a matter of adding server hardware and application software to the Application layer and ensuring that sufficient resources exist in the Control and Transport layers—quite different than purchasing a monolithic service node.
| www.radisys.com
VOICEMAIL SERVICE NODE
MOBILITY (FIND ME) SERVICES NODE
MSC (ANNOUNCEMENTS, IVR)
PREPAID/ RECHARGE SERVICE NODE
A S Voicem IP Cen Confer Videom
CONTROL
CONFERENCING SERVICE NODE
S C
SPEECH PORTAL SERVICE NODE TRANSPORT
LEGACY TDM NETWORK
IP
APPLICATION
CONTROL
APPLICATION SERVER Voicemail Calling Card IP Centrex Push to Talk Conferencing Speech Portal Videomail
CALL AGENT/ CSCF
SESSION BORDER CONTROLLER TRANSPORT
Network Gaming Ringback Hosted Services
MEDIA GATEWAY
MEDIA SERVER/ MRFP
IP
General Benefits IP- and IMS-based solutions offer strong advantages in cost and functionality over traditional solutions based on TDM, even when the terminals are in non-IP networks such as the PSTN and 2G cellular networks. With TDM, service providers find themselves locked in to the same vendor for additional equipment and new features, making new service introduction and ongoing support slower, more restricted, and more expensive. But the standardized functions and interfaces of each element in the IMS architecture allow service providers
Figure 1. TDM and VoIP/IMS Compared.
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
to buy these as individual network elements from multiple vendors using a best-of-breed sourcing model, thus significantly reducing vendor lock-in and therefore allowing less expensive total solutions. Additionally, IP- and IMS-based service platforms are generally more efficient than TDM platforms in terms of density, rack space, power, spares, and management and support effort, driving complexity and costs out of ongoing operations. On the feature side, because IP and IMS architectures are more decomposed than TDM, they are fundamentally more flexible, extensible, and future-proof. The ability to source individual components from a variety of vendors or to insert entirely new functionality into existing deployments enables much faster introduction of new services. Benefits to Messaging and UM In addition to the general benefits just covered, stateof-the-art voicemail and UM solutions derive special benefits from IP and IMS. Historically, voicemail services have been implemented as TDM-based service nodes and required a complex integration of IP packet networks for email messaging, with TDM circuit-based networks for voicemail and fax. IP/IMS-based solutions instead handle all these message/media types using a single network infrastructure, thus reducing complexity and cost and increasing functionality and flexibility.
Product Platform Evolution— ATCA & Middleware The third force is the intensifying trend in telecom toward commercial off-the-shelf (COTS) product platforms and away from proprietary platforms. Traditionally, when a vendor was creating a new network element product, they would develop it entirely in-house, including all the hardware from the chips to the boards to the chasses, and all the software from the operating system to the application code. CompactPCI started a small movement toward COTS hardware, but AdvancedTCA (ATCA), being much more capable than CompactPCI, is causing very strong interest both in ATCA as a standardized product platform and in COTS middleware for the layer between the hardware and the applications. By using commercial ATCA components and middleware, solution vendors don’t have to reinvent the wheel each time they create a new product. Voicemail and UM systems typically won’t need any specialized hardware other than for media processing, so they can be developed on top of commercial ATCA hardware as a straightforward software-development project. This
| www.radisys.com
approach reduces development cost, risk, and time to market. For the media-processing element, solution vendors can choose between purpose-built media servers and media servers on ATCA blades.
Media Processing & IP Media Servers Media processing is an important network function required by many services, including messaging. Media processing means modifying or examining audio and video streams and is the raison d’être for IP media servers and MRFPs. Media processing can be created independently from individual services because there is a common set of media-processing functions that provide all the media processing required by network services. Media processing is part of the network’s Transport layer, while the other, non-media processing aspects of services reside in the Application and Control layers.
Media Processing Building Blocks A good way to understand media processing is to treat it as a set of building blocks. These building blocks are reusable media-processing capabilities that a media server offers. Building blocks are fixed in functionality and don’t require any customization on a per-service basis; each service simply makes use of the one or more building blocks that it needs. Because media servers deliver building blocks, and building blocks are decoupled from services, media servers are also independent of services. That means adding the media processing required by a new service requires scaling the existing media servers, not changing or augmenting their functionality or buying all new types, as would have been required with TDM platforms. Media servers deployed in a network can be shared across any number of services. At a high level, the following are the media-processing building blocks that meet the needs of the vast majority of network services: 1. Play audio/video files 2. Record audio/video files 3. DTMF detection 4. Conference (mix) of audio/video streams 5. Send a fax from a TIFF file 6. Receive a fax into a TIFF file
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
7. Convert text to speech (TTS)
Volume
8. Convert speech into commands or text using automatic speech recognition (ASR)
Speed
Most of these building blocks have a number of subfeatures that can be used as the application sees fit. For example, the conferencing building block includes the ability to mute conference ports. Underlying these building blocks are some basic mediaprocessing capabilities that media servers offer. These include audio and video codecs, jitter buffers, and transcoding between media streams (often used for conferencing), and transcoding between media streams and audio or multimedia files (used for playing and recording files).
Media Processing in Messaging and UM A full UM implementation needs all but one of the core building blocks described above (the exception is Conferencing). A voicemail, videomail, or visual messaging service, on the other hand, would use only the first three building blocks (Play, Record, and DTMF). Play and Record are rich building blocks that provide many options for how to use them. All audio or video messaging services would use the Play block to play prompts and messages and the Record block to record messages. To further explain the use of these building blocks, here are some examples of the capabilities of the Play and Record building blocks that would be useful to a messaging application:
Options:
Barge-in
Repeat count
Maximum playing time
(Transcoding is automatic)
2. Record audio/video files: Destination:
Audio file
Video file
Options:
Trim pre-speech silence
Trim post-speech silence
Maximum recording time
Recording termination key(s)
Append to file
Explicit transcoding
All the other building blocks have sub-features and options, too.
1. Play audio/video files: Source:
Audio file(s)
Video file(s)
Audio variable(s): numbers, dates, times, currencies, etc., in various spoken languages File storage types:
Internal (e.g., for prompts)
External (e.g., for messages)
VCR controls:
Skip ahead, skip back
Pause, resume
| www.radisys.com
Media Streams in IP Networks—RTP There are many formats for audio and video streams in non-IP networks, such as DS0, T1, T3, E1, E3, OC-3, STM-1, Frame Relay, ATM, and so on. But in IP and IMS networks there is only one, universal format for audio and video streams: the Real Time Protocol (RTP). No matter what the format of an audio/video stream in a non-IP network, it can always be converted (by a media gateway) to/from an RTP stream in an IP network. Because IP media servers are elements of IP networks, they deal with media only in the form of RTP streams. The IP network in which media servers are typically present is called an IP core network, and non-IP access networks, such as the PSTN and 2G wireless, and IPaccess networks often surround such a network. Media servers are able to support all services and, indirectly, all access types because they are located in IP core networks and are separated from non-IP access networks by the media gateways.
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
APPLICATION SERVER BUILDING BLOCKS
SIGNALING
APPLICATION SERVER
SERVICE SPECIFIC LOGIC
SERVICE DATABASE & MANAGEMENT
SUBSCRIBER WEB INTERFACE
MEDIA SERVER SELECTION & I/F
CALL SIGNALING INTERFACE
CHARGING INTERFACE
IP MEDIA SERVER BUILDING BLOCKS CONTROL INTERFACE
AUDIO/VIDEO STREAMS
PLAY AUDIO FILES
RECORD AUDIO FILES
DTMF DETECTION
CONFERENCE AUDIO
PLAY VIDEO FILES
RECORD VIDEO FILES
CONFERENCE VIDEO SWITCHED
CONFERENCE VIDEO MIXED
SEND FAX
RECEIVE FAX
TEXT-TOSPEECH
SPEECH RECOGNITION
CODECS
AUDIO TRANSCODING
VIDEO TRANSCODING
MEDIA SERVER
Other Types of Processing To fully understand what media processing is, it’s useful to understand what it’s not. Media processing does not include anything that doesn’t involve audio and video streams, such as: Signaling
Looking now at messaging services, the above list of exclusions means that, for example, media servers would not be involved in: Presenting visual messaging interface to users Providing user notifications, e.g., by SMS or email
Service logic
IMS & Media Servers/MRFPs
Database use
Now that the role of media servers and IP media processing are understood, this section will describe how they fit into networks in general and IMS networks in particular. The examination will start with a very simplified network view and move to more complex ones.
Charging (billing) record generation Visual (e.g., web) interfaces presented to users to control or manage their service and messages Handling of SMS, MMS, instant message (IM), and email Interfacing to non-IP networks such as TDM Firewalling to other IP networks All except the last two items are the responsibility of Session Initiation Protocol (SIP) application servers, which also have the task of controlling media servers. The last two items describe functionality that is provided by media gateways and session border controllers, respectively. As noted above, once a non-IP audio or video stream passes through a media gateway it becomes an RTP stream, and a media server would perform media processing on it just as if that stream had originated within an IP network.
| www.radisys.com
Media Server and Application Server The previous section briefly introduced the role of the SIP application server. Figure 2 graphically illustrates the split between application-server features and mediaserver features, and the relationship between them. The diagram also introduces two key concepts: first, that media servers and their building blocks are controlled by application servers through a control interface; and second, that signaling is handled only by application servers while audio/video (RTP) streams are handled only by media servers. Both of these network elements—application servers and media servers—have well-defined roles, and those roles are completely complementary. A key difference is that the service-specific logic of an application is unique to its particular application, while media servers are independent of, and shared by, all applications.
Figure 2. Media Server and Application Server Building Blocks.
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
Note that Figure 2 shows only a conceptual model of application servers. A more accurate model would have all the application server building blocks except for Service-Specific Logic grouped into an application server platform, with a collection of applications (each one just Service-Specific Logic) sitting on top.
APPLICATION SERVER
MANAGEMENT
SIP, MGCP, H.248,…
Web, SNMP,…
Control Media
MRCP
RTP
RE-PACKETIZE
Play audio/video files Record audio/video files DTMF detection Conference (mix) of audio/video streams Internal Storage Send a fax from a TIFF file Receive a fax into a TIFF file Text to speech (TTS) Audio/video prompts Speech recognition (ASR) transient use
ENCODE
Real-Time IP Media Stream (RTP)
DECODE
The previous section presented the two most important media-server interfaces, control and media (RTP). As Figure 3 shows, there are actually five major interfaces supported by IP media servers, all of which would likely be used by a rich UM solution:
DE-PACKETIZE
BUILDING BLOCKS EXAMPLES
Other Media Server Interfaces
HTTP, NFS,… SPEECH SERVER
FILE SERVER
Management Audio/video prompts Recorded messages
File server Speech server Management The control and media interfaces were covered previously. The management interface allows service provider support personnel to perform Fault, Configuration, Accounting, Performance, and Security (FCAPS) management on the media server, through the media server’s management GUI or an external element management system. Web GUIs and SNMP are the most common human/machine and machine/machine interfaces for FCAPS. File Server The file server interface supports playing and recording of files—both audio and multimedia—from and to external files servers. The media server reads and writes the files using file-transfer protocols, the most common of these being HTTP and NFS. A media server typically also has internal nonvolatile storage, suitable for “canned” announcements. An external file server is required for large-volume storage of messages such as voicemail and videomail Speech Server The speech server interface allows the media server to control one or more external speech engines for services that require ASR and/or TTS. The speech server interfaces in use today are Media Resource Control Protocol Version 1 (MRCPv1) and MRCPv2. Version 1 is
10 | www.radisys.com
based on Real Time Streaming Protocol (RTSP) while Version 2 is based on SIP; both use the Session Description Protocol (SDP) and RTP. MRCPv2 is in the process of replacing v1 in the market.
Highly Simplified IMS architecture The description of how media servers fit into IMS will start with a highly simplified view of IMS. This view roughly matches the traditional VoIP architecture (which is now giving way to the IMS architecture). Shown in the middle of Figure 4 are the four most important architectural elements of any IP network architecture that includes VoIP and IMS. Each of these elements has a well-defined role: 1. The Call Agent, which converts between non-IP signaling (e.g., SS7) and IP signaling (usually SIP); also controls the media gateway 2. The Media Gateway, which converts between non-IP bearer channels (e.g., TDM) and IP bearer channels (RTP) 3. The SIP Application Server, which executes the application logic for services and controls the media server 4. The IP Media Server, which performs media processing in the IP network
Figure 3. Media Server Interfaces.
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
The call agent and application server are both involved with signaling, while the media gateway and media server are involved with media streams. The call agent controls the media gateway and the application server controls the media server. (As an aside, these four elements are all present, from an architectural point of view, inside the monolithic TDM service nodes mentioned earlier.) Only the application server (in the Application layer) “understands” services; the call agent (in the Control layer) and the media gateway and media server (in the Transport layer) have no knowledge of what services they are involved in. An application server uses third-party call control (3PCC) mechanisms to control both media servers and far-end devices (terminals and gateways) and to negotiate RTP streams between these end-points. The four architectural elements are functional components of the architecture, and in an actual deployment two or more of the elements may be combined into a single physical element in the network. This merging is most common in enterprise systems but rarer in service-provider networks. Service providers tend to prefer independent network elements (matching the decomposed architecture) because they need to scale call agents and application servers separately from media gateways and media servers, and because they want to avoid monolithic solutions and vendor lock-in. It’s especially important to keep elements in different layers physically separate to allow a layer to be reused by the ones above and so that the layers can be scaled independently. An important aspect of the architecture is that all network elements are connected using standardized and IPbased protocols. The most common protocols are SIP for signaling; H.248 and MGCP for control of media gateways; SIP, H.248, and MGCP for control of media servers; and RTP for IP media streams.
IP CORE NETWORK SS7
PHONE H.248, MGCP H.248, MGCP CELL PHONE
Most important with respect to the media server is the decomposition of the application server into a pure Application Server (AS), a Service Capability Interaction Manager (SCIM), and a Multimedia Resource Function
SPEECH SERVER
IP ACCESS IP PHONE
MRCP
SIP, H.248, MGCP
FILE SERVER HTTP, NFS
TDM
PDA/3G PHONE PC
RTP MEDIA GATEWAY
RTP IP MEDIA SERVER
RTP RTP
PEER NETWORK
SESSION BORDER CONTROLLER
Figure 4. Highly Simplified IMS View.
Controller (MRFC). The call agent is the most affected by the evolution to IMS and is broken into a number of components including three Call State Control Function (CSCF) elements, a Home Subscriber Server (HSS), a Media Gateway Control Function (MGCF), and a Signaling Gateway Function (SGF).
APPLICATION LAYER
AS
AS
AS
SCIM S-CSCF/ I-CSCF
CONTROL LAYER HSS
MRF
IBCF
P-CSCF/ RACS/PDF
MGCF/ SGF
MRFC
TRANSPORT LAYER
IP MEDIA SERVER
IP TRANSPORT NETWORK I-BGF
IMS-MGW
BAS/A-BGF/ PDG/GGSN
MRFP
INTERNET SGSN/ MGW
ACCESS LAYER BSC 2G WIRELESS
Figure 5. Simplified IMS View.
11 | www.radisys.com
SIP, H.248, MGCP
APPLICATION SERVER
SIP
TDM ACCESS
Simplified IMS Architecture—MRFP Figure 5 presents a much more accurate view of the IMS architecture, although still somewhat simplified. This view decomposes most of the components from Figure 4 into smaller and more specialized components. As before, all the components are interconnected by standardized IP-based protocols.
CALL AGENT
RNC 3G WIRELESS
CMTS CABLE
DSLAM DSL
WAG WLAN
PSTN
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
The IP media server, being already a pure function, is unaffected by IMS but is called a Multimedia Resource Function Processor (MRFP). The combination of the MRFC and MRFP is called a Multimedia Resource Function (MRF), but this architectural element is of less interest since it rarely appears as an actual network element. Instead, it is much more common to see the MRFP (media server) as a real network element.
Control Interface Protocols The IMS architecture specifies the use of a 3GPP variant of SIP for all signaling. In IMS the path from the AS to the MRFC is considered signaling, so it too uses 3GPP SIP. The various media gateways in IMS are controlled using H.248. For historical reasons, IMS calls for the media-gatewaycontrol protocol, H.248, for the control interface between the MRFC and the MRFP. Media servers currently deployed, however, mostly use SIP (with some MGCP still remaining) as a control interface and there are a number of reasons to expect that this practice will continue as networks transition to the IMS architecture. No matter which protocol is used to control an IP media server or MRFP, its role and functionality are always the same.
UM Solution Architectures The IMS architecture and the role, functions, and interfaces of a media server (MRFP) having already been described, this section will apply the information and expand upon it to describe some of the architectural alternatives related to media processing that are involved in designing a messaging solution. The alternatives will cover ways to control the media server and ways to include fax and speech processing.
Control Interface Alternatives There are four protocol alternatives to explore for controlling a media server such as RadiSys’. One uses H.248 and three are based on SIP. (MGCP is a legacy protocol and should not be used for new designs.) These alternatives can be divided according to whether they comply with the IMS principles of decomposition and layering that were presented above:
Compliant with IMS decomposition/layering: 1. H.248 2. SIP with MSML 3. SIP with VoiceXML Not compliant with IMS decomposition/layering: 4. SIP with VoiceXML, without SIP application server Any of the first three alternatives are quite workable for a messaging solution and each has its own advantages and disadvantages. The second and third options, SIP with MSML and SIP with VoiceXML, are generally preferred because they’re aligned with the industry-wide preference for SIP. Of the two, SIP with MSML is the most powerful. The availability of these three options gives solution vendors the flexibility to choose what best suits their system architecture. The fourth alternative, the one without an application server, is not recommended. It’s included in this examination because it still appears in the market, despite being a legacy architecture. We’ll examine each of these four options below. Option 1: H.248 H.248 is the ITU-T and IETF standard for IP media gateway control. (In the IETF it is known as Megaco.) It was developed as a replacement for the IETF’s MGCP, which although IP-based, is now very much a legacy protocol. By removing the non-IP portions of H.248 and adding extra functionality, H.248 can be used as a media-server control protocol. The required profiles and packages of H.248 for media server use are standardized but, as noted above, H.248 is not as popular as SIP for media server control.
SIP
H.248
RTP
Figure 6. H.248.
12 | www.radisys.com
APPLICATION SERVER
MEDIA SERVER H.248
FILE SERVER
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
H.248 handles both audio and video and supports all the media-processing blocks described earlier. The application server uses H.248 (and the Session Description Protocol, SDP) to set up media streams between terminals and the media server, and to tell the media server what media-processing tasks to perform on those streams. Figure 6 shows how H.248 is used by the application server to control the media server. The service-creation mechanism used in the application server could be anything, for example CCXML, VoiceXML, and/or SIP servlets. Option 2: SIP with MSML SIP is the IETF standard for IP communications signaling and also the most popular protocol for the control of media servers. The Media Server Markup Language (MSML) is an IETF Internet Draft defining a language for the control of SIP media servers and has become a de facto industry standard. MSML defines the syntax for XML scripts that are carried either in SIP INFO message bodies or in a long-term TCP connection negotiated using SIP. Like H.248, SIP combined with MSML supports audio and video and all the media-processing blocks described earlier. The application server uses SIP (and SDP) to set up media streams between terminals and the media server, and uses MSML to tell the media server what media-processing tasks to perform on those streams. Figure 7 shows SIP and MSML being used by the application server to control the media server. Architecturally (that is, ignoring protocols) this option is identical to the H.248 option above. As with H.248, the service-creation mechanism used in the application server could be CCXML, VoiceXML, and/or SIP servlets. Option 3: SIP with VoiceXML VoiceXML is an XML-based interactive voice response (IVR) scripting language developed by the W3C; the current versions are VoiceXML 2.0 and 2.1. Being an IVR language, VoiceXML supports only playing, recording, DTMF detection, automatic speech recognition (ASR), and text-to-speech (TTS); it can’t support conferencing (except in a very limited way using the element) or fax. VoiceXML today supports only audio media processing, although a number of vendors have introduced proprietary extensions for video. The W3C is currently defining VoiceXML 3.0, which will add support for video and other new features.
SIP
APPLICATION SERVER
SIP+MSML
RTP
MEDIA SERVER MSML
Figure 7. SIP with MSML.
Unlike MSML, VoiceXML is not carried in SIP and it is not sent between the application server and the media server. Instead, VoiceXML is carried in HTTP and is sent between the VoiceXML HTTP server and the media server. The protocol between the application server and the media server is SIP using a Request-URI syntax called Netann (RFC 4240). Using this syntax the application server tells the media server what initial VoiceXML script to fetch from the HTTP server; from then on, the VoiceXML interpreter within the media server interacts only with the HTTP server. VoiceXML, just like MGCP, H.248, and SIP, was not designed for use with media servers. VoiceXML was developed as an IVR service-creation language. There are some parts of the language, therefore, that aren’t applicable to media servers, the most obvious of these being the call-control element. Option 3 (SIP with VoiceXML) doesn’t make use of so it’s compliant with IMS decomposition and layering. (Note that is included in VoiceXML for historical reasons; if VoiceXML were being designed today it would not have .) Figure 8 illustrates how the application server can use SIP and Netann to control the media server, and how HTTP with VoiceXML is used between the media server and the VoiceXML HTTP server. Architecturally this option is very different from (and more complex than) the H.248
VOICEXML HTTP SERVER Scripting
SIP, ETC.
APPLICATION SERVER
SIP+NETANN
RTP
MEDIA SERVER VoiceXML
Figure 8. SIP with VoiceXML.
13 | www.radisys.com
FILE SERVER
CAN BE SAME
HTTP+VoiceXML
FILE SERVER
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
and SIP MSML options described earlier. As before, the service-creation mechanism used in the application server could be CCXML, SIP servlets, or anything else. Because the W3C developed CCXML as a call-control language to complement its VoiceXML IVR language, CCXML is an obvious choice for VoiceXML-centric solution developers. Option 4: SIP with VoiceXML without AS The fourth option isn’t recommended because it doesn’t comply with IMS decomposition and layering principles. It’s included in this examination because it’s still encountered in the market, despite being a legacy architecture. This option makes use of SIP, HTTP, VoiceXML, and a VoiceXML HTTP server as in Option 3. But the application server and media server are combined into a monolithic entity that performs both call control and media processing, and is sometimes confusingly called a “media server.” This option makes use of VoiceXML for call control and requires support for the element. Being a monolithic architecture it offers service providers less flexibility, scalability, and extensibility and less opportunity for best-of-breed sourcing. Figure 9 shows SIP and RTP to the “media server,” and HTTP with VoiceXML being used between the media server and the HTTP server.
Fax Processing Alternatives The second set of messaging alternatives deals with how to support fax functionality, specifically, sending and receiving faxes. There are two main options, both shown in Figure 10. Option 1 (left) uses a separate fax server that provides fax features. In the case where the application server knows a priori that a media stream is connected to a fax device at the far end, the application server will immediately connect that stream to the fax server, without using the media server at all. For the other case (no a priori knowledge), the application server will connect the stream to the media server and instruct it to turn on detection for fax tones in the background. If the media server detects these tones it will notify the application server, which will then immediately move the media stream over to the fax server.
14 | www.radisys.com
VOICEXML HTTP SERVER Scripting
CAN BE SAME
HTTP+VoiceXML
SIP RTP
”MEDIA SERVER” VoiceXML
FILE SERVER
Figure 9. SIP with VoiceXML, without Application Server.
There are fax servers available on the market with a SIP MSML control interface, which makes them as easy to use as an IP media server. Option 2 (right) has the fax features integrated into the media server. For the case where the application server knows a priori that a media stream is connected to a fax device at the far end, the application server will immediately connect that stream to the media server and instruct the media server to perform the fax send/ receive. For the other case (no a priori knowledge), it will instruct the media server to turn on detection for fax tones in the background. If the media server then detects these tones it will notify the application server, which will then immediately tell the media server to start receiving the fax.
SIP
RTP
SIP
APPLICATION SERVER
RTP
MEDIA SERVER Fax Detection
RTP
Figure 10. Fax Options 1 and 2.
FILE SERVER Fax Processing
APPLICATION SERVER
MEDIA SERVER Fax Processing
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
SIP
SIP
APPLICATION SERVER
APPLICATION SERVER
MRCP
RTP
MEDIA SERVER
RTP
SPEECH SERVER
RTP
MEDIA SERVER
WAV FILE
MRCP
SPEECH SERVER
RTP
WAV FILE
Figure 11. Speech Options 1 and 2.
Speech Processing Alternatives The third and final set of architecture alternatives covers support of speech processing, that is, ASR and TTS. Figure 11 shows the two key options. With both options, the speech server is a separate entity from the media server because speech servers are highly specialized network elements provided by different vendors than media servers. Note that with both options, the media server is always the point of attachment for the RTP stream to the far-end terminal or gateway. As described earlier, MRCP controls speech servers while RTP handles the media stream into or out of the speech server (to or from the media server). In Option 1 (left), the application server controls both the media server and the speech server. This option works for the H.248 and SIP MSML media server control protocols but doesn’t work for SIP VoiceXML because VoiceXML, which executes in the media server, embeds speech processing commands. There are two sub-options to Option 1, illustrated as the RTP and WAV File portions of the diagram. In the RTP sub-option, which works for both ASR and TTS, the application server uses third-party call control to the media server and the speech server to negotiate an RTP stream between the two when speech processing is required. The WAV File sub-option is usable only for TTS, because it involves the use of a WAV file from the speech server to the media server, instead of a bidirectional RTP stream. In this sub-option the application server instructs the speech server to generate a WAV file in faster than real
15 | www.radisys.com
time and to place it on a file server; it then instructs the media server to play that WAV file. This approach has the advantage of enabling the TTS play-out to make use of all media server Play functionality, such as fixed prompts, variables, DTMF generation, barge-in, and interactions with DTMF detection and Recording. The WAV File suboption can be used alongside the RTP sub-option when both ASR and TTS are required. With Option 2 (right), the speech server is controlled by the media server, which is itself controlled by the application server. This option works for any media server control protocol that includes speech-processing commands, such as H.248, SIP MSML, and SIP VoiceXML. Option 2 supports the same two sub-options as Option 1, RTP and WAV File.
RadiSys Media Server Solutions This section briefly presents RadiSys’ media server products and their benefits, RadiSys’ partners’ solutions, and a case study of a RadiSys deployment for voicemail.
RadiSys Products Convedia Media Servers RadiSys Convedia media servers are deployed around the globe in a large variety of VoIP and IMS multimedia service applications. All members of the Convedia product family share the same multimedia-processing features, control-interface options, and management features, facilitating their use across a large range of deployment sizes and needs.
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
The family, as shown in Figure 12, includes the following models:
Purpose-Built Media Servers
Purpose-built, DSP-based media servers: 1. CMS-1000 Media Server: 300 ports, 1 RU 2. CMS-3000 Media Server: 360 ports, 1 RU 3. CMS-6000 Media Server: 18,000 ports, 12 RU 4. CMS-9000 Media Server: 24,000 ports, 12 RU Software-based media servers: 5. Software Media Server—planned to be available in 2007 for the RadiSys Promentum ATCA-4300 Compute Processing Module (see below) and other platforms Promentum ATCA The RadiSys Promentum ATCA family includes a fully integrated application-ready platform and modular building blocks configurable for multiple applications. RadiSys ATCA delivers a common managed platform for Application- and Control-plane uses as well as Transport-plane uses (including media servers). By employing the same product platform for a variety of applications, telecom equipment manufacturers can reduce their overall development time by up to half and significantly reduce development, life-cycle, and equipment costs.
cms-6000
tier 1 carrier
cms-3000
cms-1000 small carrier & large enterprise software media servers modular software & hardware Software-Based Media Server
One of the products of the Promentum line is the ATCA-4300 Dual-core Dual Xeon Compute Processing Module, which is planned as a supported platform for the Convedia Software Media Server as described above.
Benefits for Messaging Solutions Convedia media servers (MRFPs) are pure IP-media servers that fit perfectly into VoIP and IMS architectures, solutions, and networks and fit service providers’ preference for best-of-breed sourcing of individual network elements. These world-leading media servers all support the same control, media, and management interfaces, the same media-processing features, and the same narrowband, wideband, and video codecs. They support the widest set of open standards for mediaserver control, including SIP, Netann, VoiceXML, MSML, MGCP, and H.248, and easy-to-use Web-based and SNMP management interfaces.
16 | www.radisys.com
cms-9000
ATCA Compute Processing Module
carrier & enterprise Figure 12. RadiSys Media Server Products.
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
Convedia media servers offer industry-leading port densities and are the most mature, robust, and widely deployed media servers in the market. As a family, they offer the widest range of deployment options available in a single media-server line, all the way from tens of ports up to tens of thousands of ports. With the choice of software-based or DSP-based processing, these servers meet all types of media-processing needs from the simplest G.711 announcements or IVR to the most complex video transcoding or conferencing.
Partner Solutions
Convedia media servers, both DSP-based and softwarebased, are completely software driven. This means that new features are introduced entirely through software updates instead of hardware changes, making them very flexible and future-proof. In the multi-card CMS-6000 and CMS-9000 units, one card type handles all media processing. All Convedia models support a mix of audio and video and a mix of different media-processing building blocks on a completely dynamic basis.
AT&T operates one of the world’s largest networks, carrying almost 10 petabytes of traffic daily. In the United States it’s the #1 local voice service provider, the #1 long-distance service provider, the #1 broadband service provider, and the #1 wireless service provider.
Our solution partners know that Convedia media servers reduce time to market, cut development costs for the solution, shrink product cost, and decrease ongoing support costs compared to other media-processing alternatives. RadiSys’ exclusive focus on media servers and embedded platforms eliminates any potential competitive overlap with our solution partners, making us an ideal business partner. Our service provider customers value the robustness and manageability of RadiSys media servers, which offer redundancy, no single point of failure, in-service software upgrades, and the ability to scale capacity by simply adding a single card type. RadiSys media servers are already supported by many leading messaging vendors, with a growing list of deployments at leading service providers around the world.
Beyond Messaging The value of RadiSys media servers go far beyond messaging and unified messaging. Because our media servers offer generic, reusable building blocks, they can serve the needs of all services in the network that need audio and video media processing. And each and every media server can serve the needs of multiple applications simultaneously.
17 | www.radisys.com
An important part of the overall RadiSys media server solution offering is our ecosystem of partners at all levels, including application vendors, solution vendors, system integrators, and application service providers. Through this ecosystem of partners, whose solutions cover most areas of telecom services, RadiSys is able to support a wide variety of ready-to-go solutions.
AT&T Case Study—IP Voicemail
The AT&T Business VoIP (BVoIP) service portfolio is one of the most extensive in the market today and is used by about 80% of Fortune 1000 companies. This brief case study looks at one of the many services in the BVoIP portfolio, IP Voicemail, which is part of the IP Centrex offering. The involvement of RadiSys in AT&T’s VoIP services began in 2003 with a single RadiSys media server lab evaluation system at AT&T Research in Florham Park, New Jersey. AT&T Research initially used the media server as part of a prototype for a consumer VoIP service. This project was commercialized the next year (2004) as CallVantage. AT&T’s successful commercial deployment led the company to select the RadiSys CMS-6000 Media Server for three business services, one of which was IP voicemail. Multiple RadiSys media servers were deployed for all three services in 2005. RadiSys media servers are used today in five revenuegenerating services at AT&T, and to date AT&T has deployed over 45 RadiSys media servers across these five services. AT&T is now at the beginning of a multi-year program to evolve its VoIP network to IMS and to begin migrating its many TDM-based services to IP. RadiSys looks forward to supporting AT&T and its growing media processing needs on an ongoing basis.
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
Conclusion
References
IP-based voicemail, videomail, visual messaging, and unified messaging all represent excellent opportunities for service providers—and therefore for messaging solution providers. These opportunities stem from growth in new services and especially from the replacement of aging legacy voicemail systems.
IETF
New messaging solutions are being built using IP technologies and the IMS architecture, which present vendors and service providers with big improvements in the design and deployment of messaging and most other solutions.
2. “The SIP INFO Method”, IETF, RFC 2976, S. Donovan, October 2000
A key component in the new technologies and architecture is the IP media server, called the Multimedia Resource Function Processor (MRFP) in IMS. Media servers perform, in a service-independent and reusable way, all the audio- and video-processing required by network services and support a number of standard protocols for control. IP media servers deliver a large improvement in functionality, performance, robustness, and density compared to TDM-based media processing. RadiSys’ Convedia media servers are the leading IP media servers in the world. They offer the widest range of deployment options available in a single media-server family, all the way from tens of ports up to tens of thousands of ports. With a choice of software-based or DSP-based processing, they meet all types of mediaprocessing needs from the simplest enterprise to the most complex service-provider requirements.
18 | www.radisys.com
1. “SIP: Session Initiation Protocol”, IETF, RFC 3261, J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, June 2002
3. “Basic Network Media Services with SIP”, IETF, RFC 4240, J. Van Dyke, E. Burger, A. Spitzer, December 2005 (a.k.a. “Netann”) 4. “Media Server Markup Language (MSML)”, IETF, Internet Draft, A. Saleem, G. Sharratt, October 2006, work in progress
W3C 5. “Voice Extensible Markup Language (VoiceXML) Version 2.0”, W3C, W3C Recommendation, March 16, 2004 6. “Voice Extensible Markup Language (VoiceXML) 2.1”, W3C, W3C Working Draft, September 15, 2006
RadiSys 7. “Controlling Media Servers with SIP”, RadiSys White Paper, June 2004 8. “Overview of RadiSys’ IETF Internet Draft on Media Server Markup Language (MSML)”, RadiSys White paper, September 2006
RADISYS Whitepaper | ip media servers and ims in voicemail and unified messaging
Corporate Headquarters 5445 NE Dawson Creek Dr Hillsboro, OR 97124 USA Phone: 503-615-1100 Fax: 503-615-1121 Toll-Free: 800-950-0044 www.radisys.com
[email protected] ©2007 RadiSys Corporation. RadiSys is a registered trademark of RadiSys Corporation. Convedia, Microware and OS-9 are registered trademarks of RadiSys Corporation. Promentum, and Procelerant are trademarks of RadiSys Corporation. *All other trademarks are the properties of their respective owners. 07-1343-00 0407
19 | www.radisys.com
