Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 35: JAINTM INAP API Specification

Stage Access Start Finish
Final Release Download page 05 Mar, 2002  
First Release Download page 24 Aug, 2001  
Public Review Download page 14 Feb, 2001 16 Mar, 2001
Participant Review Login page 10 Oct, 2000 09 Nov, 2000
CAFE   17 Sep, 1999 05 Oct, 1999
JSR Approval   03 Sep, 1999 17 Sep, 1999
Status: Final
JCP version in use: 1.0
Java Specification Participation Agreement version in use: 1.0

This JSR is to develop the JAINTM (Java APIs for Integrated Networks) INAP (Intelligent Network Application Protocol) specification for Intelligent Network Applications in the Telecommunications Industry.

Please direct comments on this JSR to the Spec Lead(s)

Specification Leads
  Shankar Allimatti Mahindra British Telecom Ltd.
Expert Group
  AePONA Datakinetics Limited Ericsson Inc.
  Mahindra British Telecom Ltd. Motorola Nokia Corporation
  Nortel Samsung Electronics Corporation Siemens AG
  Sun Microsystems, Inc. Telcordia Technologies, Inc. Ulticom

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1: Identification

Contact Information:

Shankar Allimatti,
Mahindra British Telecom Limited.
Phone: +91 20 77-4740

This JSR is being submitted and endorsed by the following Java Community Process Participants:

  • Sun Microsystems
  • APiON Ltd
  • DGM&S Telecom
  • ADC Newnet
  • Ericsson
  • Telcordia
  • Trillium Digital Systems
  • Mahindra British Telecom Limited

Section 2: Request

This JSR is to develop the JavaTM APIs for Integrated Networks (JAIN) Intelligent Network Application Protocol (INAP) Specification. It will describe the Java standard API for Intelligent Networks application's interaction in the Telecommunications Industry.

2.1 What is INAP?

INAP protocol allows applications to communicate between various nodes/functional entities of an intelligent network. The protocol defines the operations required to be performed between nodes/functional entities for providing Intelligent Network services. INAP handles number of services such as number translator, time of day, follow me, etc.

2.2 Target Java Platform

The JAIN INAP Specification is targeted towards telephony over integrated Public Switched Telephone Networks (PSTN) , mobile telephony networks, and Internet Protocol networks. This will typically be NEBS Certified equipment or servers that support SS7 or Signaling environments.

2.3 Needs of Java Community this Specification Addresses

Traditionally, telephony applications require costly resources to develop, test, and deploy. A JAIN cross-platform solution gives the Carriers, Service Providers, and Network Equipment Providers a consistent, open environment where they can rapidly develop and deploy telephony services dynamically. The JAIN INAP specification defines an API which allows for the rapid creation and deployment of telephony services into a Java telephony platform. A JAIN INAP component can be rapidly developed, tested, and integrated on a variety of platforms with access to numerous tools and utilities.

2.4 The API being defined.

The API specified by the JAIN SS7 Java Community Process Participants for INAP are based on the ANSI/Bellcore AIN and ITU-T CS-1 INAP specifications. Instead of mapping the standard specifications to a Java interface, the JAIN INAP specification abstracts a functional definition into the variant protocol stacks.

The JAIN INAP API is built upon the Java Beans Event model. The protocol stack vendor supplies the JAIN INAP 'provider' interface into the protocol stack. JAIN INAP 'listeners' may readily be rolled onto the platform by an object manager.

Proprietary stack features are hidden behind a JAIN INAP Factory. Through JAIN INAP interfaces, a protocol stack provider is obtained from the factory, and JAIN INAP listeners are then attached to the providers.

2.5 Underlying technologies

The JAIN INAP specification is based upon the underlying SS7 protocol stacks supplied by the JAIN JSPA members and other 3rd party protocol stack implementations and its initial purpose is to provide a ubiquitous, standard Java interface into SS7 protocol stacks.

A JAIN INAP application can be written as a program, applet, servlet, or bean. The Java bean makes for an ideal telephony component for rapid dynamic service integration. The Telecom industry has defined telephony services built by integrating components in a Service Creation Environment (SCE). The service is then loaded onto a Service Logic Execution Environment (SLEE) where they receive incoming calls and perform the service logic. Telephony components are analogous to objects or Java Beans. A Service Logic Execution Environment may be built within a Java Virtual Machine using Java Bean technology. The SLEE requires Java Beans and a Java Bean Management tool. Service Creation Environments may be built using Java visual tools such as Java Studio, or Visual Cafe.

While there is no dependency on such tools to build a JAIN INAP component, a Java Bean Manager and/or a visual Java bean builder aids in the development, integration, testing, and deployment of telephony services.

2.6 Proposed package names

Package names being considered are:


This package contains the main interfaces, classes and exceptions required to send and receive INAP messages.

2.7 Possible platform dependencies

The Reference Implementation may have a dependency on RMI.

2.8 Security implications

None. JAIN INAP expects to utilize standard JDK security.

2.9 Internationalization implications

JAIN INAP is based on ITU-T specifications. Hence the API can be readily adopted in the European networks.

2.10 Localization implications

Since JAIN INAP also supports ANSI/Bellcore standards, the INAP API can be readily adapted to North American networks.

2.11 Risk assessment

JAIN platform alongwith JAIN INAP and other interfaces moves Java into telco carrier grade service. The Telecom Industry levies Stringent performance and failure requirements on hardware and software platforms. Risks include failure of the Java platform due to poor performance or the inability to failover or recover. Performance evaluation and tests based on API architecture will be published with each release of the API. Failover will be measured and published based on latency to recover to a like platform and recover state data through JDBC interfaces or Transaction based tools.

Section 3: Contributions

Documents describing JAIN can be found at