- Shopping Bag ( 0 items )
From the Publisher"if it is in your office library do borrow it" (SIGS Application Development Advisor, October 2001)
"...gives the history of the Java programming language..." (SciTech Book News, Vol. 26, No. 2, June 2002)
Java has taken the computing world by storm - now it arms itself to conquer telecommunications!
What links today's hottest programming language to telecommunications? The same characteristics that brought about Java's remarkable success on the Internet: its platform independence and mobility.
Recent developments such as JAIN (Java APIs for Integrated Networks), JAIN Parlay and the Java Telephony API equip Java for the next generation of telecommunications systems and networks. The authors, all practitioners at companies such as Sun Microsystems and Telcordia, provide the first comprehensive overview of how Java will be employed in areas such as call control, intelligent networking, STN/Internet convergence, and integrated network management.
As well as providing a high-level survey of architectures and protocols, Java in Telecommunications also gives detailed guidance on implementation strategies for the brand new, still evolving, technologies:
* call and multimedia processing;
* Voice Over IP (VOIP) Telephony;
* eXtensible Markup Language (XML);
* Enterprise Java Beans (EJB).
Java in Telecommunications is aimed at experienced telecommunications network practitioners who need to plan strategically for the future as well as all those who want to stay ahead of the game and embark upon Third Generation networks and services.
Providing the first comprehensive overview of how Java may be employed to create telecommunications networks of the future....
"...gives the history of the Java programming language..." (SciTech Book News, Vol. 26, No. 2, June 2002)
Future telecommunications networks will be characterized by new and evolving architectures where packet-switched, circuit-switched, and wireless networks are integrated to offer subscribers an array of innovative multimedia, multi-party applications. Equally importantly, it is expected that the process by which telecommunications applications are developed will change, and will no longer solely be the domain of the telecommunications network or service provider. In fact, in order to provide a broad portfolio of novel, compelling applications rapidly, service providers will increasingly turn to third-party applications developers and software vendors. Thus application development in the telecommunications domain will become more similar to that in the software and information technology in general, with customers reaping the benefits of increased competition, reduced time-tomarket, and rapid leveraging of new technology as it is developed.
To make this vision a reality it is necessary that future integrated networks offer application developers a set of standard, open application programming interfaces (APIs) so that applications written for one vendor's system can run on a different vendor's system. This will enable the cost of applications development to be amortized, reducing the final cost to the customer. The JAIN" community is a community of companies led by Sun Microsystems under the Java Community Process that is developing standard, open, published Java" APIs for next-generation systems consisting of integrated internet protocol (IP) or asynchronous transport mode (ATM), public switched telephone network (PSTN) and wireless networks. These APIs include interfaces at the protocol level, for different protocols like MGCP1, SIP, and TCAP, as well as at higher layers of the telecommunications software stack.
One of the key APIs being developed at the higher layers of the telecommunications stack is the API for defining the call model that the network offers the applications developer. The call model can be regarded as a specialized virtua13 machine for the development of telecommunications applications [1,2], with the API being the interface to that virtual machine. In this chapter we describe such an API developed by a subgroup of JAIN, called the Java call control (JCC). We stress here that the use of the phrase "call model", which has traditionally been associated with the PSTN, does not imply that the work of the JCC Edit Group is focused on the PSTN. The charter of the JCC group is to develop an API that applies equally well to IP or ATM, PSTN, and wireless networks, as well as networks integrating these technologies.
The development of open network APIs using Java represents an important departure from traditional methods by which the PSTN was made more open. In the past, advanced intelligent network (AIN) defined models that allowed the creation of services outside switches, but typically these services were written in specialized languages, using specialized service creation environments, by specialized personnel. The benefits and potential pitfalls of using Java as a language for implementing telephony APIs have been discussed in , and for implementing protocols in . We will not repeat these discussions here; the reader is referred to [3,4]. However, we point out that aside from the benefits of the Java language itself (such as portability across different execution platforms), using Java allows the arsenal of Java-based technologies (Java Beans, Enterprise JavaBeans, etc.) to be applied to service development for telecommunications services. In addition, the growing number of tools, support utilities, development environments, and experienced programmers and designers available for Java potentially opens up large economies of scale in the service creation process. Finally, we have previously implemented a prototype call-processing platform in 100% pure Java that completes basic calls, performs advanced services, and also allows dynamic service deployment [1,2].
This chapter is organized as follows. In Section 2 we will briefly survey existing call models and APIs, including AIN, JTAPI, and Parlay. In Section 3 we describe the architecture and design of the JCC version 1.0 API and its components in some detail, focusing on a narrative explanation of its principal features rather than a line-by-line retelling of the specification. (Note that this material is not a substitute for the specification itself, which is the definitive source. The specification is available freely from the Sun Java website, currently at http:lljava.sun.comlaboutJavalcommunityprocesslfinal.html.) In Section 4 we illustrate the use of the JCC 1.0 API with two examples. The first example is a simple two-party call origination, while the second example illustrates the power of the JCC API in allowing standardized as well as customized event filtering during the invocation of applications. In Section 5 we present a more detailed discussion of the relationship of JCC with JTAPI and Parlay call control, focusing on how the structure of JCC is designed to allow logical compatibility with these other APIs and the industry segments that the three APIs address. Finally in Section 6 we end with some brief concluding remarks.
3.2 Call models and APIs
The JCC API defines a programming interface to next-generation converged networks in terms of an abstract, object-oriented specification. As such it is designed to hide the details of the specifics of the underlying network architecture and protocols from the application programmer to the extent possible. Thus, the network may consist of the PSTN, a packet (IP or ATM) network, a wireless network, or a combination of these, without affecting the development of services using the API. The API is also independent of network signaling and transport protocols. Thus, the network may be using various call control protocols and technologies, for example, SGCP, MGCP, SIP, H.323, ISUP, DSS 1 /Q.931, and DSS2/Q.2931, without the explicit knowledge of the application programmer. Indeed, different legs of a call may be using different signaling protocols and be on different underlying networks.
It is assumed that the network will be able to notify the platform implementing the API regarding events that have occurred and the platform will be able to process the event as necessary and inform the application using the API. In addition, the application will be able to initiate actions using the API that the platform will translate into appropriate protocol signaling messages to the network. It is the job of the platform to interface to the underlying networks) and translate API methods and events to and from underlying signaling protocols as it sees fit. We stress that this translation is vendor-specific and is not specified by the API; thus different platform vendors may differentiate and compete based on the attributes (e.g. performance) of their translation.
Traditionally, the word "call" in the PSTN evokes associations with a two-party, point-to-point voice call. In contrast, in this chapter and within the JAIN JCC Edit Group, we use the word call to refer in general to a multimedia, mufti-party, multiprotocol communications session over the underlying integrated (IP, ATM, PSTN, wireless) network. By "mufti-protocol" we mean here that different legs of the call, representing the logical connection to individual parties of the call, may be affected by different underlying communications protocols over different types of networks. Thus, one leg of the call may be affected using the H.323 protocol , another via SIP , and a third via traditional PSTN signaling protocols like ISUP . JCC can be used to set up multimedia sessions, provided they can be modeled using the abstractions provided by the JCC API. Note, however, that JCC is not intended to provide fully-fledged control of multimedia streams, such as synchronization facilities, control of different substreams, etc., these would be provided by additional packages built on top of JCC.
Several call models and associated APIs have been developed in the past, including AIN , Java telephony API (JTAPI) [9,3], and telephony API (TAPI) . While there are important differences among these call models, reflecting the architecture or application for which they were intended, their overall goal is generally similar: to initiate, control and manipulate calls, and to facilitate the development of applications that execute before, during or after a call. Rather than select any one particular call model, we believe it is worthwhile to learn from the experience gathered by the different communities that have developed existing call models, and develop a generic call model suitable for integrated next-generation networks.
For example, the AIN call model was designed to allow applications to be developed for the PSTN. Thus, the AIN call model implicitly assumes a specific distributed architecture where telephone switches perform the basic call processing functions. It is assumed that value-added services (e.g. toll-free number translation, time-of-day call routing, etc.) are executed, before or during calls, by a specialized service logic execution environment (SLEE) like the service control point (SCP). In contrast, JTAPI focuses on call processing and applications for a private branch exchange (PBX) or call center environment, where a much greater degree of centralized processing and control is the norm. Thus, unlike AIN, JTAPI contains no facilities for suspending execution of call processing and invoking applications during call set-up or mid-call. On the other hand, unlike AIN, JTAPI offers convenient, object-oriented abstractions for call manipulation, which facilitate the rapid development of object-oriented applications.
A survey of all existing call models we have considered is outside the scope of this chapter. In the following subsections we briefly review three existing call models and APIs that are especially relevant to our efforts, namely AIN, JTAPI and Parlay.....
Java APIs for Integrated Networks.
Java Call Control.
Realtime Java for Telecommunications.
Java for Network Management.
XML and Java for Telecommunications.
Glossary of Terms.