JAIN APIs Q&A

Yes, the JAIN specifications do provide endless ways to implement them. Firstly each implementation to each vendors' stack will different as each vendors' stack expose different proprietary APIs. Secondly each vendor will be able to implement between the two APIs in many ways depending on certain design decisions that they decide to adopt. This opens the competition between vendors to provide the best solution.

In JAIN, is there an asynchronous message mechanism, or is there just a synchronous API invitation?

The protocol APIs support asynchronous and synchronous implementation's of the specifications, ie, when an application(Listener) invokes an operation on a stack(Provider), the implementation of the interface decides whether control is handed back to the application to continue other operation invocations or locked until a response is returned from the stack.

It seems that there is some, if not a lot of overlap between JAIN, JMX, JDMK, and OSS through Java. Will these technologies merge, somehow complement with each other, or eventually be dropped?

Indeed these are closely related technologies, but they are very complimentary to one another and there are certainly no plans for any of these to be dropped.

It should be noted that three of the four technologies that you list (JAIN, OSS through Java, and JMX) are all API extensions that have been defined through the Java Community Process (JCP) by collections of industry players.

- The JAIN APIs address the signaling, call processing, and services layers in the telco space (converged telco, ie, PSTN and IP, wireline and wireless). The JAIN APIs are optional extension packages to either J2ME, J2SE or J2EE.

- The OSS through Java APIs address the operation support system interfaces (also often referred to as Back Office Systems). The OSS though Java APIs are optional extension packages to J2EE. More information about OSS through Java can be found at: http://java.sun.com/products/OSS/

- JMX defines management interfaces that can be deployed in any industries (not just telecom), wherever management is needed. JMX is an optional package addition to J2SE. More information about JMX can be found at: http://java.sun.com/products/JavaManagement/JAIN and OSS through Java take advantage of JMX whenever possible for underlying management capabilities. So rather than replicating JMX functionality, JAIN and OSS/J use JMX and build from it. Unlike JMX, JAIN and OSS through Java, JDMK is not an API (or set of APIs) defined through the JCP. Rather, JDMK is a product that is available from Sun... JDMK is the implementation of the JMX API specification. More information about JDMK can be found at: http://www.sun.com/software/java-dynamic/

I have developed a SIP Stack using C/C++. My understanding is that anybody who implements the SIP protocol should not have any interoperability issues for SIP applications. Is it a worthwhile effort for me to adopt the JAIN SIP API on top of my SIP stack?

Yes, most definitely. Adopting the JAIN SIP API enables SIP applications to be written once and run anywhere on any vendor's platform or stack (providing the JAIN SIP API is exposed). This is of obvious benefit to application developers, SIP platform vendors and carriers. Interoperability is in fact the goal of the SIP interoperability events that are regularly held.

Do the JAIN APIs that are targeted at 3GPP OSA support distributed application functionality such as CORBA?

Whilst the JAIN SPA activity produces Java implementations of the Parlay / ETSI / 3GPP specifications, it currently does not specify or mandate any particular distribution mechanism. The APIs being produced by the JAIN SPA activity can be viewed as being local APIs and the reason why this approach was taken was to make the interface to the application programmer as clean and easy-to-use as possible. Distribution can of course be supported below the JAIN SPA APIs, however the JAIN SPA Expert Groups believe that this should be hidden to the application programmer.

Is there any underlying transport layer for the JAIN APIs, particularly JAIN SPA e.g. IIOP, DCOM, SOAP?

This question is partly covered in the answer to the question above, but here is further related information... JAIN SPA and in fact all the JAIN specifications are pure Java APIs and do not mandate underlying transport. All of the APIs can be realized on IIOP, Corba, DCOM, SOAP, ...etc.

What is the difference between OSA, Parlay and the JAIN specifications?

3GPP OSA, Parlay, ETSI and the JAIN community are working on fully aligned technology independent API specifications and fully aligned OMG-IDL. The JAIN community is, through the JAIN SPA activity, producing programmer friendly, object oriented, distribution mechanism independent Java implementations from the technology independent APIs. The JAIN SPA APIs then can be used with the other JAIN APIs and the standard Java APIs, together with environments such as J2EE, to provide the application programmer with a powerful set of Java APIs ideal for creating, deploying, running and managing a diverse set of applications.

These collaborative activities provide input into the JAIN SPA APIs, which produces Java technology realizations of the UML specifications whilst ensuring that the resultant output aligns with and leverages the other API activities ongoing within the JAIN program.

Is interoperability a major concern for JAIN?

Interoperability is not a concern for JAIN. Interoperability is targeted at protocol to protocol - JAIN is concerned with application to protocol, enabling vendor independence and service portability. If the applications adhere to the JAIN specifications they will be interoperable via the protocol.

Can you enlighten us as to what are the software requirements other than JDK and suggest the practical development, which can be done using the JAIN API?

JAIN is concerned with all aspects of telecommunications. From the complete set of SS7 protocols to the range of IP protocols namely, SIP, MGCP, Megaco and H323. JAIN specifies a wide range of Service Provider protocols, Call Control API's and an Execution Environment for applications built on these protocols. Depending upon which area of telecommunications you are focusing on, you would select from the suite of JAIN Specifications to satisfy your needs.

In order to implement a specific JAIN API - lets take SIP, you would need to implement or buy a SIP stack (software module), download the JAIN SIP API and implement it down to that SIP Stack. Alternatively the stack vendor may supply you with a SIP stack that already exposes the JAIN SIP API. The benefit of adding this JAIN SIP layer onto the SIP Stack is that you now have a standardized JAIN SIP API upon which all vendor independent JAIN SIP applications are portable.

How does JAIN help in building communication applications like FollowMe, Unified Messaging etc..?

JAIN doesn't necessarily help with the complexity of developing a specific application such as FollowMe, however it does help in that the service only has to be implemented once, since it is portable. For example, FollowMe can be implemented on the TCAP Layer of a SS7 stack. Therefore if you were using vendor X?s stack you would write the service to vendor X?s proprietary TCAP API. If you wanted to change stack vendor for some reason say to vendor A, you would have to re-write the FollowMe service to vendor A's proprietary API. If both vendors expose the JAIN TCAP API the service is only written once, thereby providing stack vendor independence for the Service Provider and hence increased competition for the stack vendors.

I am looking for JAIN APIs Packages in installable versions like JDK1.3. Also Simulation tools like SS7 simulation and Switch simulators. Can you help?

The only installable version of the JAIN APIs is the API JAR file that contains the binary classes you include in your classpath. An important point is that the JAIN APIs are only an API not a specific protocol implementation. They are a thin Java wrapper layer that any protocol vendor can implement to enable application portability and open networks on that specific protocol of their stack.

The closest item that JAIN provides to the simulator is the Reference Implementation. The RI mostly only provides a simple converter that accepts requests and replies with response. Its only requirement is that it is a proof of concept implementation that runs against the TCK. An important point to realize is that the JAIN initiative is enabling the industry and open Java API's that vendors implement on top of their products are provided.

I would like to know how a Web Call Center can be implemented using JAIN SPA. Could you tell me how it could be done after the service access invocation? In other words, the user makes the authentication, get the token for the requested service and gets the manager interface for this service. Particularly, how this can be achieved by using a JAIN Softswitch?

First of all it should be noted that there are the Parlay Call Control APIs and JCC. JCC is intended for the JAIN Softswitch and JCC is a simplified Java version of Parlay MPCCS. Suppose the Web server sets up a call, we call this a third-party call. The web server needs to navigate to a provider object eg: JcpPeer.getProvider. A provider supports the createCall method. The JccCall object resulting from this method supports the routeCall method. Typically, you want to invoke this twice. Each routeCall, in the case of third party call, will result in the creation of a JccConnection object. Both connections will eventually hit the ALERTING state (if all goes well). ALERTING means that the end-users terminal is alerting. JCC abstracts from the underlying network, actual protocols, such as SIP or ISUP, take care of inviting/alerting the user.

Can the JAIN APIs be implemented on a Linux based platform?

As long as you use the Java SDK for Linux and have a protocol stack that operates on the Linux platform then the JAIN APIs are compatible with Linux.

What kind of modifications can be imported to the JAIN API to meet the demands of our proprietary implementation?

The JAIN APIs are a set of specifications to a various protocol stacks. All JAIN based stacks will look the same from the applications view, hence applications authored to the JAIN APIs will be stack vendor independent. As a result of this the JAIN APIs can't be modified. However since most of the APIs are defined as interfaces, a developer can implement the interfaces as they choose allowing them to suit their proprietary implementation.

Is it mandatory that the protocol stacks using the JAIN APIs are written in Java or are other alternatives (e.g. C++) implementations acceptable as well?

Your protocol stack can be written in any language e.g. Java, C++ or C. The JAIN APIs enable you to implement a Java wrapper around your protocol stack. Applications that run on the JAIN APIs will be developed in Java, similar to any Java application running over the JDK.

How does the JAIN framework address the concept of a protocol between call control entities like softswitches and application/feature servers? Currently - the International Softswitch Consortium (ISC) recommends SIP for this in the application framework document.

The JAIN family of APIs provides a rich set of interfaces from which many different architectural solutions can be devised. For the interface between a call control server (softswitch) and application server, there are several options. One could implement a pure SIP interface (as recommended by the ISC), and this SIP interface could be facilitated via the JAIN SIP API (which maps directly to the SIP protocol). This kind of approach is suitable if your network is pure IP and SIP is your protocol of choice. One then could put JCC on the app server for application development.

Another option is to have JCC (along with optional extensions like JCAT) on the softswitch and/or on the Application Server for application development. If SIP is in place as the wire protocol, then JCC can use it as a resource for transport, with JCC providing the programming interface for application development. In this case a mapping between JCC and SIP is needed - see the White Papers & Articles section for this document.

We have seen other approaches where JCC is used on the Application Server which then interfaces to a proprietary call control API on a Softswitch. However placing JCC on both the softswitch and the Application Server provides the ultimate flexibility and portability of basic services on the softswitch, and enhanced services on the Application Server.

JAIN APIs Q&amp;A