The Common Gateway Interface (CGI) for Session Initiation Protocol (SIP)
INTERNET-BASED SERVICES 164
is not really a framework more an extension of the mechanism used by web servers to invoke server side scripts. Made popular by Dynamicsoft, it is a mechanism that can be easily built into an application server/proxy server/registration server platform that can allow users to upload scripts written in CPL (see Chapter 8), that execute on the server.
The CGI used on web servers evolved as a mechanism for generating dynamic content and processing form submissions from web pages.
SIP CGI works like a traditional web (hypertext transfer protocol) CGI, when a request (in this case a SIP INVITE message) arrives at the server, the message and all its parameters are passed to a script through the standard input and sets a number of environment variables that contain information about the message and where it came from. The script on the server executes and uses the information stored and the standard input to make decisions on its behaviour.
In a HTTP CGI implementation the script generates a response (which in most cases is HTML to send back to the client that created the original request) and exits. SIP CGI is different in this respect. The output of the script can actually be an instruction to create a new request. In the case of a SIP proxy server (see Chapter 5) this is quite likely to be the result of the execution of the script.
An HTTP CGI script is normally transaction driven, with each request a single response is made, with no context as to any previous transactions. With SIP CGI however this would not be useful, since the SIP CGI script can generate a request itself, then sometime later a response would be expected, clearly the original script that generated the request needs to be informed of the response. State is maintained through the use of ‘script cookies’. The cookie is passed as part of the response to the CGI server in environment data, this cookie is passed back to the script when another request arrives. Armed with a cookie and the new request the script can maintain state between transactions [RFC3050].
Since its creation the web CGI has been augmented with servlets and server side scripting. Servlets (see Section 12.3 on J2EE for a description of Java servlets) are a Java replacement for the CGI, instead of the web server running a separate process to execute CGI code, the Java virtual machine on the web server runs a servlet code.
SIP servlets extend the idea of Java servlets to SIP messages, allowing applications to quickly and easily have access to all the information in the SIP messages. This, it is hoped will speed the delivery of server side SIP aware applications. The SIP servlet API is now part of the Java community programme and the hope is that SIP servlets will form part of the Java 2 Standard Edition and Java 2 Enterprise Edition APIs in the future. This small addition to J2EE (if it is incorporated) would make it possible for all application servers, that are J2EE compliant, to be capable of becoming media control/call servers.
OSS-J
There is one last word on frameworks that is possibly even more impor- tant than what we have already covered. It is the OSS through Java initia- tive. This initiative is looking to simplify the complexity of Operational Support Systems (OSS) through the use of J2EE and specifically the enter- prise JavaBeanse. The OSS-J community programme is looking to build
on work already underway in the Third-Generation Partnership Programme (3GPP) and TeleManagement Forum and to provide a set of Java APIs, source code and component models that will be freely distrib- uted. Conventional OSS and Business Support Systems (BSS) involve lots of integration issues between different vendors’ equipment; OSS-J looks to address these issues. If it is successful it may signal a new era for management of complex services and just what is needed and necessary to provide the importantgluebetween the new services and the operation, maintenance and billing for them.
The OSS-J initiative is currently focused on deliverables for the 3G mobile networks and specifically the areas of:
† service activation (create, amend and cancel)
† quality of service (support, operability, serviceability and security) and
† trouble ticketing (fault tracking and resolution)
The Java community process demands the following deliverables: APIs for each of the areas above, a reference implementation and a technology compatibility kit (essentially a toolset with a collection of tests to prove other platforms conform to the specification). More detail can be obtained from http://java.sun.com/products/oss, and I suggest the interested reader check here for all the latest developments.
In closing, the frameworks presented in this chapter will form the basis for many of the xSP application server platforms and softswitch services that were discussed in the previous chapter. XML is probably the most important component incorporated into all the frameworks discussed, it will form the glue that describes the services, their configuration and the protocols they use to communicate. The big names are keen to move in this space and people like Oracle, Dynamicsoft and BEA (and others) already have key products in the application server marketplace. The link between application servers and softswitches is the next step that will complete the next-generation network architecture.
INTERNET-BASED SERVICES 166