Stack a web services API on a web server interface to easily access signaling and data plane protocol stacks

Mobile telecommunications and the global Internet are two world-changing technologies that have revolutionized the way people and businesses communicate. Both the telecommunications revolution and Internet technology started due to military requirements, but over the past 20 years each has grown by leaps and bounds in the public sector.

During the last five years, as people have leveraged telecommunications and the Internet for business purposes, there have been major innovations in e-commerce that have levied new requirements on the traditional TCP/IP network paradigm. As a result, the Internet has grown much beyond basic data transport services to include advanced application development frameworks including Java, XML, dotnet, c#, frameworks, templates and so on.

The Web Server Application is one of the popular frameworks leveraged by developers to deliver new services over the Internet. Original Equipment Manufacturers leverage this capability to provide readily deployable application servers, which allow dynamic web page generation and implement services like clustering, fail-over and load balancing so that developers can be focused just on implementing the business logic of the target application.

While the Internet has expanded with a sharp focus on improving the end-user experience, it was not until recently that telecommunications networks attempted to move beyond their own traditionally closed intricacies. The foundation of telecom networks has been C-based software stacks and lightweight-but-C-based end user Application Programming Interfaces (APIs). Only in recent years has the telecommunications sector adapted to use more web-based interfaces along with custom applications, but even they have primarily been limited to Network Management Systems (NMS) and Element Management Systems (EMS), as well as the Operational Support Systems (OSS) and Business Support Systems (BSS) side of the telecommunications network. Despite the potential of many web-related e-applications being deployed on top of existing standard telecommunications APIs, the deployment of web server or Java-based applications has been minimal. The challenge is that there are limited tools that make available the underlying services of the telecommunications network to application developers in an easy-to-use and familiar web server environment.

The solution is to add a web services API on top of integrated standards-based signaling and data plane telecommunications protocol stacks to offer the application developer access to these protocols for communication purposes via a straightforward and familiar web server interface. An example of such a solution includes Continuous Computing’s offering of a Web Services Description Language (WSDL) interface ported on top of deployment-proven Trillium protocol stacks. With solutions such as this, application developers can write complex applications in the programming language and/or platform of their choice using the web services request and response without delving into the details of the specific protocols or getting restricted by the inflexibility of C/C++ APIs.

Intelligent Networks and TCAP

The Intelligent Network (IN) standards provide a framework for service-oriented architecture-based networks, which separate the service control functionality from the switching functionality. The aim is to provide seamless service to all subscribers regardless of underlying switching network which include ISDN (Integrated Services Digital Network), PSTN (Public Switched Telephone Network), PLMN (Public Land Mobile Network) and so on. Before IN was developed, new services had been implemented in the switching system itself. This is a tedious task as debugging the switch takes considerable time and is an inflexible method as often-new services required costly changes to the foundational switching network. This approach leads to slow deployment of new features or services and stalled innovation. The main advantage of IN is that the new services are introduced without any changes in the networking infrastructure – which means that new services are deployed faster and less expensively.

In addition to the IN construct, another important aspect of rapid service deployment is the requirement for a generic service architecture that works over different switching networks. Additionally, the service deployment framework should be designed so that new features or services can be added easily with the reuse of existing service or feature components. Hence the concept to develop generic and reusable service components such as authentication, number translation, charging, etc., which could be used across various applications. Premium Rate and Card Calling are some of the several examples of IN services using reusable service components. In summary, IN aims to support both service and network independence while providing many innovative services.

The IN relies on the Signaling System 7 (SS7) network, which forms its backbone. Indeed, SS7 provides the basic infrastructure needed for the IN. There are multiple network elements in the IN including:

* Service Switching Point (SSP): the SSP provides local access services as well as an ISDN interface to the Service Transfer Point.

* Service Transfer Point (STP): the STP provides packet switching of message-based signaling protocols in IN to the Service Control Point.

* Service Control Point (SCP): the SCP provides access to the IN subscriber database and is connected to a Service Management System.

* Service Management System (SMS): the SMS provides a graphical user interface to the subscriber database, which supports update and overall management of the database.

* Intelligent Peripheral (IP): the IP provides resource management of devices such as voice response units, voice announcers, and DTMF (Dual Tone Multi Frequency) sensors for caller-activated services. The SCP accesses the IP when service demands interaction.

Within the IN protocol framework; Transaction Capabilities Application Part (TCAP) is an application layer protocol, which provides generic services for the information transfer between applications in the SS7 network. It uses a standards-defined set of data elements to support the information transfer. TCAP is based on the concept of components; components are a means of invoking an operation on a remote node. A TCAP message can contain several components. In TCAP, transactions are a set of related messages that are exchanged between nodes. The services of TCAP are provided according to two sub-layers, the component sub-layer and the transaction sub-layer.

When a call is placed in the IN, a request for call handling instructions is sent to the SCP using the TCAP protocol. The database provides the instructions for handling the call based on the customized service instructions programmed by the subscriber and sends them to end office switch.

The call setup and teardown is handled using the conventional SS7 protocol. Many services and features offered by the network are based on the database linked to the SS7 network through the SCPs’ local end offices and other networks can access the database by sending database query messages through the SS7 network to the SCP. These databases are used for intelligent call routing, Local Number Portability, Prepaid services, VPN and other intelligent network services. These services can be accessed through the TCAP messages exchanged between SS7 network elements.

Internet and SIP

As recently as five years ago, and even for many people today, there is a hard reliance on expensive circuit switched mobile and PSTN networks to carry voice calls over short as well as long distances. However, the advent of Voice over IP (VoIP) has delivered a cost-effective solution that leverages the widely deployed Internet for delivering voice services.

Instead of sending signals via a Circuit Switched network, a VoIP application generally uses the Session Initiation Protocol (SIP) built on top of the TCP / IP framework of the Internet to set up voice and video calls or “sessions” over IP networks.

SIP is now the de-facto foundational protocol in many VoIP solutions. It is a signaling protocol used for establishing sessions in an IP network. SIP not only provides the ability to establish real-time calls and conferences but also enables a number of innovative services such as voice-enriched e-commerce, web page click-to-dial, Instant Messaging with buddy lists and IP Centrex services.

SIP is a request-response protocol that closely resembles two other Internet protocols, HTTP (Hyper Text Transfer Protocol) and SMTP (Simple Mail Transfer Protocol) – the protocols that power the World Wide Web and email; consequently, SIP sits comfortably alongside Internet applications. Using SIP, telephony becomes another web application and integrates easily into other Internet services. SIP is a simple toolkit that service providers can use to build converged voice and multimedia services.

In order to provide telephony services there is a need for a number of different standards and protocols to come together – specifically to ensure transport (RTP), to authenticate users (RADIUS, Diameter), to provide directories (LDAP), to be able to guarantee voice quality (RSVP, YESSIR) and to inter-work with today’s telephone network.

Prevalent with web application development, a Java Specification Request (JSR) has standardized SIP Servlet APIs, which run in a SIP container and are similar to HTTP Servlets but also support the SIP protocol. Together, SIP and SIP Servlets are behind many popular applications that provide VoIP services.

Convergence of IP and IN

Advanced services can be provided on top of VoIP networks with the usage of IN services such as Unified Messaging that can be delivered as email to the called party and provisioning of services where queries specific to the PSTN Network become requirement pictures. Additionally, operators who are today providing a series of calling services to their subscriber base on the legacy IN infrastructure want to continue to provide these same services as they transition subscribers to a more cost-effective all-IP based network that uses VoIP frameworks.

For using such integrated services, a mechanism is required by which a network element that has the ability to utilize SIP signaling can make use of PSTN features via SS7 TCAP signaling. For using any of the services of PSTN networks, SIP signaling information must traverse the IP network to a Signaling Gateway to get access to the SS7 network. There are two factors involved here. First, the SIP endpoint needs to format a binary TCAP message or use an intermediate representation that is then converted to a binary TCAP message by the Signaling Gateway. Second, the SIP element needs to use SIP itself for the transport or possibly some other transport mechanism to deliver the TCAP message to the Signaling Gateway. The solution that this paper recommends is the use of gSOAP messages to transport and receive intermediate representations of TCAP messages from the SIP endpoint to the Signaling Gateway. Figure 2 illustrates the flow of signaling in the SIP / TCAP-based signaling gateway.

Many intelligent services can be built leveraging this integration gateway. For example, Local Number Portability (LNP) is one of the services that can be achieved through this gateway. URI (Uniform Resource Identifier) is a string of characters for identifying a resource on Internet. In SIP, URI is an addressing scheme for identifying caller or callee. E.164 is an international numbering plan for public telephone systems in which each assigned number contains a country code (CC), a national destination code (NDC) and a subscriber number (SN). When the SIP Server receives an INVITE request, it extracts the useful info (E.164 number) from the request URI. It builds the TCAP request in the form of a SOAP client and sends it to the TCAP web server using gSOAP. Similarly, if a SIP server receives the 800 Number requests in the request URI, it builds an equivalent query using SOAP client and sends it to TCAP server using gSOAP.

Web Services and SOAP

A web service is a network-accessible interface to application functionality that is built using standard Internet software languages. Web services provide an abstraction layer between the client and application. Most web services today, like booking a ticket or banking, are provided through HTML websites. Application services are provided through the use of HTTP protocols and HTML (Hyper Text Markup Language) data formats. Both the client and server application understands these standards and interact with the web services for different services. Because of these standards, it does not matter whether the application is written in C++ or Java.

Web services are capable of sending and receiving messages using HTTP Internet protocol and some defined message format understood by the client and/or server. The most common example of web services is to call procedures running on the application server.

For the application data to be communicated between client and application, it needs to be in a common format. HTML is a kind of packaging format, but it is not very suitable for conveying the meaning of specific data elements. XML (eXtensible Markup Language) is the most common packaging format because it represents the meaning of data more closely through the use of metadata tags. Additionally, XML parsers are easily available via the open source community. SOAP is very common and popular packaging format built on top of XML. SOAP can also be thought as a sort of Remote Procedure Call (RPC) that uses XML. SOAP is an XML-based protocol from the W3C for exchanging data over HTTP. It provides a simple, standards-based method for sending XML messages between applications. Web services use SOAP to send messages between a service and its client(s). Because all Web servers and browsers support HTTP, SOAP applications exploit a wire-protocol (typically HTTP) to communicate with Web Services to retrieve dynamic content. For example, SOAP can be use to deliver real-time stock quote information of a stock portfolio that can be graphed on the display of a cell phone or can be analyzed within a spreadsheet program running on a desktop computer. SOAP neither enforces client service architecture nor supports P2P (peer-to-peer) architecture.

WSDL is an XML-based format for describing Web Services. It described the subroutine and its argument through which a service is to be accessed. Clients wishing to access a Web Service can read and interpret its WSDL file to learn about the location of the service and its available operations. In this way, the WSDL definition acts as the initial Web service interface, providing clients with all the information they need to interact with the service in a standards-based way. Through the WSDL, a Web Services client learns where a service can be accessed, what operations the service performs, the communication protocols the service supports and the correct format for sending messages to the service.

SOAP messages are in XML document format. Data is sent between the client(s) and the Web Service using request and response SOAP messages, the format for which is specified in the WSDL definition. Because the client and server adhere to the WSDL contract when creating SOAP messages, the messages are guaranteed to be compatible. A large number of SOAP Toolkits are available for different programming languages. In short, SOAP is a protocol that uses WSDL to deliver Web Services in a standard and extensible fashion.

TCAP Web Server using gSOAP

gSOAP is an open source SOAP Toolkit for C and C++. The gSOAP tools provide an automated SOAP and XML data binding for C and C++ based on compiler technologies. The tools simplify the development of SOAP/XML Web Services and XML applications in C and C++ using automatic code generation and advanced mapping methods.

gSOAP provides a transparent SOAP API through the use of compiler technology that hides irrelevant SOAP-specific details from the user. The compiler automatically maps native and user-defined C and C++ data types to semantically equivalent SOAP data types. As a result, full SOAP interoperability is achieved with a simple API relieving the user of the burden of SOAP details and enabling him/her to concentrate on the application-essential logic. The gSOAP stub and skeleton compiler provides a unique SOAP-to-C++ language binding for the development of SOAP-enabled applications such as clients, services and peers.

TCAP services can be provided as a web service to any third party hosting a VoIP Application such as a SIP proxy server for an 800 Number translation service. VoIP applications can have a TCAP client code embedded in their application and by leveraging SOAP/WSDL can request a TCAP Begin or Continue message. Essentially, the embedded client can make TCAP requests of the IN using SOAP without detailed knowledge of or interaction with the underlying SS7 transport. This means VoIP applications can leverage existing TCAP-based IN applications and services in delivery of their services ensuring application re-use and service continuity.

After designing the WSDL, the client- and server-side code can be generated using the gSOAP-provided tools. Whenever a VoIP application wants to make a request it will use the generated client code (i.e., a function call) to make any telephone-related query in the IN.

An example of the WSDL code is as follows:

The most important advantage of this architecture is that even if the client is using a Java-based application, the Web Server can use a C-based implementation over a common WSDL/SOAP infrastructure. This is a very similar approach as used in the CORBA (Common Object Request Broker Architecture) framework and WSDL may be compared with IDL (Interface Definition Language) in Java.

Solution Example: TCAP Web Server

This section provides an example solution that leverages proven Trillium TCAP and standard WSDL / SOAP to deliver a TCAP gateway application. This gateway allows any VoIP entities to access the TCAP-based IN services hosted in a traditional SS7 network. It may be deployed as a nationwide-hosted database or an SCP in a specific carrier’s network. Service requests originate from a SIP proxy server, or any VoIP entities, and the TCAP gateway is gSOAP-based. The interface files are provided in the form of WSDL (XML files) that provide the details of the TCAP services. Using these files, client code is generated to be embedded in the VoIP / SIP-based application. The following diagram illustrates this solution approach.

The WSDL defines the interface to the TCAP stack and is derived from the standard Java programming API for TCAP, JSR11. There are two separate WSDLs defined for communicating with the TCAP interface for simplicity and brevity:

1. send.wsdl: used to send a TCAP Web Service from the SIP Servlet to the TCAP interface

2. process.wsdl: used by the TCAP interface to send Web Service from the SS7/SIGTRAN to the Servlet

The WSDL allows the application to specify all parameters associated with the SCCP N-UNITDATA request primitive, including all variations of the routing parameters (e.g., Destination PC + SSN, Global title, Routing Indication, etc…) when sending a message.

The following represents a typical scenario flow:

TCAP Web Server is used as the Gateway solution to the VoIP entity as shown in the call flow below for any services hosted by the SS7 networks SCPs. The UE receives an INVITE, which is translated into the TCAP Web query using the gSOAP client code. The TCAP web server application passes this query to the STP/SCP after receiving on the gSOAP server interface.

The TCAP Gateway Stack architecture is shown in the figure below. It contains the TCAP protocol stack, which consists of multiple protocol layers including TCAP, SCCP, M3UA and SCTP protocols. The TCAP solution also provides a Stack Manager for the protocol stacks, which provides initialization, configuration and general Operations, Administration and Maintenance (OA&M) functionality. The solution also provides high availability through an active-standby configuration. The proven Trillium Fault-Tolerance / High Availability (FT/HA) architecture is used here, but for simplicity is not illustrated in the diagram.

The following outlines two services that can be enabled using a WSDL/SOAP-based TCAP Gateway.

Originating Call Screening (OCS)

Originating Call Screening (OCS) is a service whereby the Proxy Server ensures that the caller is authorized to initiate a call to the dialed number otherwise known as the callee.

When the SIP proxy server receives an INVITE request, it extracts the Request-URI (an E.164 number) of the party being invited and sends it, along with other information, to the TCAP Web Service client. The TCAP Web Server Application proceeds through the Web Service Interface, triggers a TCAP (or INAP) request to the SCP.  The SCP analyzes this request and instructs the SIP proxy server on what to do next with the call. The SCP has access to a user profile database, which contains, among other fields, a field which restricts the caller from making certain calls (for example, 900 number calls, which in the US are billed at higher-than-normal rates).

Example 1: Caller wants to initiate a call to a 900 number (which is forbidden by the user’s calling plan):

Caller->Sip Server:

       INVITE sip:9005551111@ccpu.com;user=phone

Sip Server ->Caller:

      SIP/2.0 403 Forbidden

Local Number Portability (LNP)

Number portability can be classified into three types: Service Portability, Service Provider Portability and Location Portability. Service Provider portability is defined as the “ability of an end user to retain the same E.164 international public telecommunication number when changing from one service provider to another.”

Example 2: Caller calls a number, which has been ported:

Caller->Sip server:

      INVITE sip:6302240216@ccpu.com;user=phone

When the SIP proxy server receives an INVITE request, it extracts the Request-URI (an E.164 number) of the party being invited and sends it, along with other information, to the TCAP Web Server Client. The TCAP Web Server Application triggers an LNP TCAP (or INAP) request to the SCP. The SCP analyzes this request, and after consulting an LNP database, returns the new routing number to the SIP proxy server. The SIP proxy server forwards the request to the next hop SIP server, after modifying the Request-URI to include the new routing number:

Sip Server->Next Sip Server:

      INVITE sip:6307130184@ccpu.com;user=phone

The determination of the next hop SIP server can be done by various means. In our case, the next hop SIP server happened to be a properly registered User Agent Server belonging to the callee, so the INVITE was simply proxied to it.

Conclusion

The Internet revolutionized the way people interact. Telecommunications and the subsequent emergence of mobility accelerated that trend by bringing the concept of a unified experience to end users everywhere.  Network technology has had to evolve along with the industry as a whole, and one of the primary ways it has done so has been through application customization via web-based interfaces.  The only way to offer an application developer access to standards-based signaling and data plane telecommunications protocol stacks is to provide a straightforward and familiar web server interface by stacking a web services API on top.

About the Author

Alok Kumar is Director of Engineering at RadiSys (via Continuous Computing). He has a B.E. in electronics and telecommunication from Madan Mohan Malviya Engineering College, Gorakhpur, an M.S. degree in Software Systems from Birla Institute of Technology & Science, Pilani and an M.B.A. (Finance) from the Institute of Chartered Financial Analysts of India University, Hyderabad.