Standards Watch : Making Progress Toward IP-based Open APIs

There seems to be no shortage of ideas for standardizing interfaces in both PSTN and IP networks. The "write once, run anywhere" paradigm, once applied to Java technology in intelligent networks, has now manifested itself in converged data and voice networks through JAIN (Java APIs for Integrated Networks)-an initiative that operates under the auspices of Sun's Java Community Process.

"By enabling Java technology-based applications with secure access to resources inside the network, we create an opportunity to deliver thousands rather than dozens of new services," says Margaret Nilson, JAIN program manager and software engineering manager at Sun Microsystems, who cites click-to-dial, unified messaging, multimedia teleconferencing, dynamic call forwarding and other telephony and Internet services as examples where voice, data and media must converge.

By creating an open environment, Nilson says the use of JAIN could mitigate the complexities and expenses associated with today's typically proprietary mechanisms.

Thus far, JAIN APIs are being defined as a community of extensions to the Java platform, the purpose of which is to bring service portability, convergence and secure access to telephony and data in PSTN and IP networks.

"Protocols are the language of the networks for transporting and communicating among network elements," Nilson says, "while Java technology-based APIs can be layered on top of those protocols so that developers using Java technology can easily create programs using the protocols. However, Java-enabled APIs were ideal as long as developers didn't need proprietary extensions, and as long as they ran them generically across networks."

She says the problem originated with intelligent networks, where lack of service portability was prevalent. "Services built using one vendor's service creation environment would run fine on that one vendor's service execution platform and a fixed set of switches, but couldn't easily port to anyone else's networks or platforms," Nilson explains. That led to prodigious amounts of rewritten code, she says, and "locked service providers into their vendors' proprietary solutions."

While JAIN technology in its early days emerged to solve that problem for intelligent networks through SS7 protocols, it has matured to where it is now also aggressively addressing the problem for IP services. "At the protocol layer, we already have a stable suite of protocols for the PSTN and SS7 side," says Nilson. "But there is tremendous momentum building on the IP side, where a plethora of new protocols and APIs are now being defined."

"Now is the ideal time for participation from service providers," she says. As a former software development manager of intelligent network products at Telcordia, however, she understands the caution with which service providers adopt emerging technologies. "They are all investing time and money into an evolving network and service infrastructure," she says.

Nilson notes that some service providers, such as BT and NTT, have become actively involved in the standards process, providing expertise for defining new APIs and even mandating that their vendors incorporate JAIN APIs into their products. "When operators get more involved early on," she says, "their requirements are better understood in the early stages of the API development, thus expediting the process and resulting in interfaces that meet the service providers' needs."

JAIN APIs are building on the IP side, with specifications under development for SIP (session initiation protocol), MGCP (media gateway control protocol), MEGACO (media gateway control) and the H.323 standard for IP telephony.

On the application side, the JAIN community is defining a set of APIs that will enable new services to be developed independently of the underlying transport networks and protocols. These APIs include JAIN Call Control (JCC), JAIN Service Logic Execution Environment (JAIN SLEE), JAIN Service Creation Environment (JAIN SCE) and a set of Java APIs for Parlay, which are collectively referred to as the JAIN Service Provider APIs (JAIN SPA).

Nilson notes that Parlay and JAIN SPA are complementary APIs that affect the application layer, enabling service providers to open up their telecom networks to third-party application developers securely. "You don't want to let any third-party developers access any network element they want," says Nilson, noting Parlay is designed to open application development to thousands of developers, rather than small numbers in trusted networks. "Now providers can open up network resources without compromising security," she says.

The Billing and OSS Connection

"One interface of vital importance is that of the billing systems," Nilson says. "While varying interfacing architectures will be proposed, prototyped and implemented, they will all share the common requirement to track billing events during service execution, and send this data to the downstream billing systems." Ideally, she says, the billing systems will implement Java-based APIs standardized through the Java Community Process.

At the moment, working groups are developing the OSS IP Billing API, and in the near future will tackle the JAIN SPA Content-Based Charging API (based on Parlay Content-Based Charging).