Java in Telecommunications: Solutions for Next Generation Networks / Edition 1

Hardcover (Print)
Buy New
Buy New from
Used and New from Other Sellers
Used and New from Other Sellers
from $31.35
Usually ships in 1-2 business days
(Save 76%)
Other sellers (Hardcover)
  • All (12) from $31.35   
  • New (6) from $76.05   
  • Used (6) from $31.35   


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....

Read More Show Less

Editorial Reviews

From the Publisher
"if it is in your office library do borrow it" (SIGS Application Development Advisor, October 2001)

" the history of the Java programming language..." (SciTech Book News, Vol. 26, No. 2, June 2002)

From The Critics
Jepsen (editor of ) gives the history of the Java programming language in his introduction to a volume directed to programmers familiar with telecommunications networks. Five specialists, all affiliated with telecommunication companies, have written chapters that describe several new technologies, including Java APIs for integrated networks (or JAIN), Java call control, realtime Java, various Java applications for network management, and XML and Java applications for telecommunications. Annotation c. Book News, Inc., Portland, OR (
Read More Show Less

Product Details

Meet the Author

THOMAS C. JEPSON is Programming Languages Editor for IEEE IT Professional Magazine and a telecommunications industry professional who has developed a number of telecommunications-related Java applications, including graphical user interfaces and an application programming interface for Asynchronous Transfer Mode (ATM).

Read More Show Less

Read an Excerpt


Java call control

Ravi Jain and Farooq Anjum
Applied Research, Telcordia Technologies, USA

3.1 Introduction

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 [3], and for implementing protocols in [4]. 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 [5], another via SIP [6], and a third via traditional PSTN signaling protocols like ISUP [7]. 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 [8], Java telephony API (JTAPI) [9,3], and telephony API (TAPI) [10]. 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.....

Read More Show Less

Table of Contents



Java APIs for Integrated Networks.

Java Call Control.

Realtime Java for Telecommunications.

Java for Network Management.

XML and Java for Telecommunications.

Glossary of Terms.


Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)