Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 17: JAINTM ISUP Specification

This JSR has been Withdrawn
Reason: The Spec Lead of this JSR approached other members of the Expert Group to see if they might be interested in taking on the role of Spec Lead, but there has been no interest. This is due to the fact that industry focus has evolved/changed, and as such the original scope of the JSR is not as important to the industry as originally scoped. The Spec Lead has since left the JCP and the Expert Group has been disbanded.

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1: Identification

Contact Information:

Douglas Tait,
Sun Telco, Sun Microsystems, Inc.

Phone: +1 609 231-5790

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

Section 2: Request

This JSR is to develop the Java for the (Advanced) Intelligent Network (JAINTM) ISDN User Part (ISUP) Specification. It will describe the Java standard API for network call control and maintenence in the Telecommunications Industry.

2.1 What is ISUP?

ISUP provides the signaling functions necessary to basic bearer services and supplementary services for voice and non-voice applications in the Integrated Services Digital Network. ISUP is defined within the Signaling System 7 (SS7) specifications as a communications protocol used to set-up, manage and release trunk circuits that carry voice and data call over the Public Switched Telephone Network (PSTN).

2.2 Target Java Platform

The JAIN ISUP Specification is targeted towards Central Office switching environments, mobile telephony networks, and telephony over 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

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

2.4 The API being defined.

The API specified by the JAIN SS7 Java Community Process Participants for ISUP are based on the ANSI'92, ANSI'96, ITU'93, and ITU'97 ISUP specifications. Instead of mapping the standard specifications to a Java interface, the JAIN ISUP specification abstracts a functional definition into the variant protocol stacks.

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

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

2.5 Underlying technologies

The JAIN ISUP specification is based upon the underlying SS7 protocol stacks supplied by the JAIN JSPA members and other 3rd party protocol stack implementations. While JAIN ISUP adapts well to other protocols such as TCP/IP or SIP, its initial purpose is to provide a ubiquitous, standard Java interface into SS7 protocol stacks.

A JAIN ISUP 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 Environments (SLEE) where they receive incoming calls and perform the service logic.

Telephony components are analogous to objects or Java Beans. A Service Logic Execution Environments may be built within a Java Virtual Maching 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 dependancy on such tools to build a JAIN ISUP compont, 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 ISUP messages.
This package contains the Event classes representing the call processing primitives and their parameters.
This package contains the Event classes representing the ISUP Management primitives and their parameters.

2.7 Possible platform dependencies

The Reference Implementation will have a dependency on RMI.

2.8 Security implications

None. JAIN ISUP expects to utilize standard JDK security.

2.9 Internationalization implications

Because JAIN ISUP is based on ITU specifications, the API can be readily adopted in the European market. Adherance to Japanese standards will also make JAIN ISUP ready for the Asian market.

2.10 Localization implications

Since JAIN ISUP is also based on ANSI/Bellcore standards, the ISUP API can be readily adapted to most North American SS7 Protocol Stacks.

2.11 Risk assessment

JAIN ISUP moves Java into telco carrier grade service. The Telcoms Industry levies Stingent 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.

2.12 Existing specifications rendered obsolete or deprecated

Not applicable.

2.13 Existing specifications needing revisions

Not applicable.

Section 3: Contributions

Documents describing JAIN can be found at