VoIP 2.0 Meets Web 2.0

Home / Company  / White Papers / VoIP 2.0 Meets Web 2.0

Until recently, the glacial movements of the incumbent carriers made it difficult to detect watershed events in the telecom industry. But the incumbents no longer control the events that shape telecom. Instead of the de jure telecom standards of the ITU, we have industry groups, such as the 3GPP, which developed IMS, the W3C, responsible for VoiceXML and other Web standards, and the IETF, which sets Internet standards. Then the Web 2.0 crowd, such as Google, Skype, and Yahoo! are creating their own “telecom standards.” Can telecom mashups be far behind?

 

Commetrex believes that the decomposition of service networks for the carrier and enterprise into what is now being called IMS and service-oriented architectures (SOA) is defining a new approach to service-network implementation. Closely related is the utilization of Web-based servers and VoiceXML to supply the application logic and context-specific information needed to handle individual calls and subscribers.

 

This means that the “me generation” phenomenon will move beyond wireless to wireline and from wireline to the enterprise. Commetrex is basing its strategy on the understanding that communications and information are becoming personalized, more open than ever, and Web-based.

IMS And Hosted Telecom

 

The most notable development in the hosted-telecom market is the architectural separation of application logic from media-server resources by the use of mark-up languages to drive the media server from the application server. Mark-up languages, such as HTML, VoiceXML, and CCXML, are familiar to the legions of Web developers, making it far easier for a service provider, OEM, or VAR to staff a development project. Not only is the labor pool larger than telecom-specific knowledge workers, their tools are more productive than conventional programming. IMS utilizes this architecture, shown in simplified form below.

IMS Network Architecture

Another important feature, as shown above, is the separation of the service network application and session layers from the access, or connectivity layer, allowing the IP service network to be access-network independent, and for the industry to partition itself into more tightly focused areas of competencies. Commetrex’ specialization, for example, is in the access or media layer.

 

The CSCF (Call State Control Function) is the “traffic cop” of IMS. It receives a subscriber’s call, validates the caller and determines her service profile via the Home Subscriber Server (HSS), and then brokers the call to the Application Servers (ASs). The MRF (Media Resource Function…BladeWare) provides the required media services, as directed by the application servers.

 

IMS supports:

  • The business separation of services from transport: Just as the business of building and maintaining roads is different from that of service stations and restaurants, the business of building and managing networks should be different from the business of implementing and deploying value-adding services.
  • Access-network independence: With IMS, the subscribers’ access device and network can be transparent to the service.
  • Separation of call and session control from transport and media: These two functions require significantly different resources and skills to implement. Separation permits a tighter focus of the industry’s innovation and production resources. Commetrex operates on transport and media.
  • Separation of service applications and media-service resources: Media servers, the “Media Resource Function” (MRF) and the Application Servers are separated (see Figure 1). The MRF can provide disparate media services to multiple independent Application Servers. The separation of the media gateway and the media-gateway controller, and the application server and the media server are perfect examples of the use of network functional separation to achieve skill-set and resource separation in network equipment.
  • Roaming – IMS can allow subscribers to roam from enterprise to service-provider and beyond to another service-provider’s network without service interruption.

 

In addition to an open-ended list of network-based applications, the IMS architecture supports address resolution and routing, authentication, location and presence, network-based storage, and emergency services. And it is just as applicable to the enterprise as to the communications service provider. Absent “walled gardens” erected by carriers, the widespread implementation of IMS can dramatically lower the cost of developing and deploying network-based services, unleashing a torrent of innovation in new, unimagined services.

 

The MRF in the IMS Network

 

As shown in the figure above, the MRF can be decomposed into the MRFC (Media Resource Function Controller) and MRFP (Media Resource Function Processor). Commetrex is shipping a fax-specific MRF today.

SOA And Enterprise Servers

 

Much like the telecom service provider, enterprises are motivated to develop service architectures that can quickly and cost-effectively respond to new requirements. Service-oriented architectures (SOAs) promote a loose Web-based coupling between the user-facing controlling application and Web-based information and service-logic resources. The objective is to move beyond IT’s traditional many-month-to-multi-year turnaround on development requests to a highly responsive service infrastructure. The primary architecture and features of IMS applied to these requirements yield the required results. The primary difference between the two networks is that IMS requires more security and billing features than most enterprise applications.

 

BladeWare performs the media server functions.

 

Web-based services bring the army of Web developers, and the information they are making accessible, into the framework of telephony-based servers. You can also flip that to be a technology that brings telephony to the Web (not just IP). This is certainly the view of Skype, Google, Yahoo! and AOL. Service Oriented Architecture, or SOA, is now an integral part of enterprise deployments. SOA is a blueprint for an adaptable, flexible, and open IT architecture for developing services-based, enterprise-scale business solutions.

 

SOA defines an environment in which resources on a network are made available as independent services that can be accessed without knowledge of their underlying platform implementation. By aligning communications with service-oriented architecture (SOA) as part of a company’s enterprise application integration strategy, developers can improve communications and enterprise applications by integrating voice-communication capabilities with critical business applications and processes. IP media servers can play a key role in business-process communications, such as telephony, audio/video conferencing, instant messaging, contact centers, voicemail, collaboration, e-mail, and workflow automation.

VoiceXML Browsers

 

VoiceXML is the established W3C standard for voice dialog languages. VoiceXML is bringing much more value to telecom than its original developers imagined. Actually, their target was the enterprise. But now the advantages of separating the application from the network equipment and placing it on a Web server where it can be fetched on a per-call basis are so pronounced, the technology is being widely adopted by telecom service providers.

 

The VoiceXML browser is analogous to a graphical Web browser, such as Netscape®

 

with a Web server using voice or DTMF inputs. Instead of rendering and interpreting HTML (like a graphical browser), the VoiceXML browser renders and interprets the VoiceXML script, which determines how the service application interacts with the caller/subscriber. Rather than clicking a mouse and using a keyboard, the caller uses her voice and a telephone (and even the phone keypad) to access Web information and services via the MRF.

 

One of the primary functions of the VoiceXML Browser is to fetch VoiceXML documents from the Web server, just as a graphical Web browser fetches HTML documents. The request to fetch a document can be generated either by the interpretation of a VoiceXML document, or in response to an external event, such as a SIP-based command from an application server in an IMS network. The VoiceXML browser uses HTTP over a LAN or the Internet to fetch the documents (the very same HTTP requests that are used by the graphical Web browser).

 

The VoiceXML browser interprets and renders the VoiceXML document. It manages the dialog between the application and the user by playing audio prompts, accepting user input, and acting on that input. The action might involve jumping to a new dialog, fetching a new document, or submitting user input to the Web server for processing.

 

Since the user’s interaction is with a Web server, the server can be connected to enterprise or carrier databases without requiring that the database interaction be any different that with non-telecom applications. To push the example even further, the information supplied to the caller can be from a social-networking site via a mashup-oriented API supplied by the social-network operator.

 

The VoiceXML Forum (now 376 companies strong) published VoiceXML 1.0 in 2000 and then transitioned control of the specification to the World Wide Web Consortium (W3C). Since then, the W3C has published VoiceXML 2.1, and is currently working on VoiceXML 3.0 (“V3”).

 

Despite the substantial opportunity that exists in this marketplace, there are only a few significant VoiceXML platform vendors. A number of industry moves have affected that. The number-one player, GenesysLabs, acquired VoiceGenie Technologies, the number-two player. Vocalocity, the leader in VoiceXML OEM solutions, was sold to Zivva, which was re-named Vocalocity, and no longer focuses on that marketplace. Voxeo has recently strengthened its position with an aggressive marketing push. Envox, VoxPilot, and Holly are also in the mix. The leading VoiceXML open-source offering, OpenVXI, the most widely-used VoiceXML interpreter, has become dormant following an ownership change. These market dynamics have created the opening for a new player to emerge. Commetrex is that player and BladeWareVXML is the product!

BladeWare VoiceXML

With these industry moves in mind, Commetrex developed and recently announced the availability on sourceforge.net of BladeWareVXMLInterpreter, an open-source portable VXML interpreter. BladeWareVXMLInterpreter is designed specifically to integrate into an existing telephony platform. It is an enhanced version of OpenVXi, which has been adopted by more telephony platforms than any other VoiceXML interpreter. Major improvements are included in the areas of performance and VoiceXML 2.1 conformance. BladeWareVXMLInterpreterBladeWareVXML Interpreter consists of a collection of replaceable components to provide maximum flexibility to developers. Users can keep the components they need and substitute their own where appropriate. BladeWareVXMLInterpreter is also easily enhanced to support proprietary grammar formats, URI types, and VoiceXML objects.

 

BladeWareVXMLInterpreter is fully internationalized and language agnostic. It has been used in dozens of languages including US English, Mexican Spanish, Japanese, French, German, and Korean.

 

BladeWareVXMLBrowser, which includes BladeWareVXMLInterpreter MRCP, HTTP and Web-services support, will be available in early 2008.