The Telecommunications Service Provider market is rapidly moving to embrace SIP (session initiation protocol) as the next-generation “dial tone.” This move is necessary to support the change in revenue focus from lowering operations costs to expanding revenue through offering new and innovative services.

For several years the telecommunications industry has focused on forcing the SIP IP infrastructure to emulate the legacy TDM-based, audio centric, telecom service operation. The goal of everyone involved in this effort (standards bodies, equipment manufacturers, etc.) was to achieve a level of parity between SIP service networks and the legacy TDM service networks. This has been achieved and, as a result, the industry is now looking beyond simple emulation of legacy voice services and is starting to redefine the service provider application infrastructure to accommodate new services that include rich multimedia content, as well as unified communications.

As service providers design their new infrastructure, the constraints that have been built around SIP to help it conform to the legacy service model are being broken down. The result is that SIP is finally being recognized and allowed to fulfill the functionality it was originally designed for: to enable multi-modal sessions to be opened between subscribers and services in a dynamic and flexible framework.

The service providers’ focus on building out their SIP networks has turned increasingly toward forming an Application Layer on top of SIP that can provide the type of flexible multi-modal applications that can take advantage of their SIP infrastructure. The IMS and 3GPP efforts are a good example of the types of architecture being considered as service providers re-architect their infrastructures.

IMS defines a SIP Application Server as its open service creation environment. While several vendors have taken license with the definition of what a SIP Application Server is, the official definition of it is covered under JSR116, the SIP Servlet Container. This SIP Application Server provides an environment that closely emulates the Web Servlet container used commonly in data centric Web applications. The SIP Servlet Container provides easy and performanceeffective access to the underlying SIP service network. Realtime, performance grade telephony applications can be written and deployed in this environment using common Web application development techniques. Building the application layer in this way provides easy access to a large population of skilled Web application developers.

Opening up SIP application development to Web developers through JSR116 is just the initial step however. IMS and JSR 116 together provide only the starting point for developing the rich multi-modal applications that will assist Service Providers in expanding their revenue targets. The JSR116 standard is great for creating applications such as Conferencing, IVR and announcements, ACD operations, video conferencing, etc., but only the portions of that application that involve call control and routing, session establishment, media control, and message routing. Other elements of a complete application such as Web portals, complex data manipulation, user presentation, calendar management, etc., all of which involve extensive data management and non-real time interaction with external elements (subscribers), can severely impact the real-time performance of a Java-based system. Because of this, telephony applications that require these non-real-time operations will be written in a way that makes use of the JSR 116 container for the telephony or real-time aspects, and a non-real-time platform such as J2EE or .NET will be used for the data-centric operations.

The combination of a J2EE or .NET layer on top of the SIP Servlet container provides the best of all worlds for telephony service creation. The only limitation to this combination is the lack of a clear demarcation point when architecting applications. It is too tempting to build most of the application in the Web tier to simplify the developer’s task. This results in poor performance and scalability in that the performance-sensitive aspects of the application are compromised. The solution to this problem is the recent adoption of Service Oriented Architecture (SOA) techniques and the Web Services standards by service providers.

Web Services provides a set of standards that support the distribution of components of an application in a standard framework. Because it is based around standards, there are many vendors that support this infrastructure and provide tools that help develop, organize, debug, and deploy these applications. In the Web Services architecture, the SIP telephony portion of an application is exposed as a service. This SIP Telephony Service is then blended with other services at the Web tier to create a unified, logical distributed application (Figure 1).

The JSR 116 standard alone does not specify how to build a Web Services interface within a SIP Servlet container. This is a relatively new requirement that several companies are starting to address in their product lines. The standardization of a Web Services development environment on top of a SIP Servlet container will delay early implementations. This is a necessary step towards evolving the SIP telephony infrastructure toward a truly open and flexible service delivery environment. I would expect the standardization of Web Services on top of a SIP Servlet container to be well under way before the end of the year. An example of the type of application that is possible in this infrastructure is a Driving Direction service (Figure 2).

In this service, a subscriber calls the service and is directed to an auto-attendant that is implemented within the SIP Telephony Service. The auto-attendant interacts with the subscriber through voice prompts and collects DTMF digits. It may also connect the subscriber to a Speech Recognition server to record the subscriber’s desired destination. The SIP Telephony Service then would pass the subscriber’s location and desired destination up to the Web tier through a Web Services interface, where the higher layer application would interact with a public Web Service such as MapQuest to generate the requested driving directions. The Web tier application would then pass the driving direction list back to the SIP Telephony Service where it will use a text to speech server to play the directions out to the subscriber.

Applications are becoming more complex and rich in terms of the number of available options and operations. Service providers are moving rapidly to adopt new standards and architectures to better enable them to capitalize on new revenue potential. The SIP IP network that has been built within these service providers is now being awakened to its full potential and is poised to deliver on the true promise of flexible converged infrastructure.

Doug Tucker is Chief Technology Officer of Ubiquity Software. For more information, please visit the company online http://www.ubiquitysoftware.com.(news - alert)