END-TO-END IP

JAIN APIs for call control

and wireless networks
T
he JAIN APIs for Integrated
networks bring service porta-
bility, convergence, and
secure network access to telephony
and data networks. By providing a
new level of abstraction and associat-
ed JAVA interfaces for service cre-
ation across Public Switched
Telephone Network (PSTN), Internet
Protocol (IP) and wireless networks,
JAIN technology enables the integra-
tion of Internet and Intelligent
Network (IN) protocols. This is
referred to as Integrated Networks.
Since JAIN APIs include secure access
to resources inside the network, the
opportunity is created to deliver thou-
sands of services rather than the
dozens currently available.
JAIN technology is changing the
telecommunications market from
many proprietary closed systems to a
single network architecture where
services can be rapidly created and
deployed. JAIN technology is being
specified as a community extension
to the Java platform. Development is
being carried out under the terms of
Sun’s Java Specification Participation
Agreement (JSPA) and the Java
Community Process (JCP).
The JAIN initiative is targeted
toward three major areas of the net-
work:
• Wireless: Mobile Switching
Centers (MSCs)
• Internet: emerging softswitches or
call agents, and media gateway
controllers or H.323 gatekeepers.
A service layer
• Telecommunication: Service
Control Points (SCPs)
• Wireless: any combination of Base
Station Controllers (BSCs), Home
Location Registers (HLRs), Visitor
Location Registers (VLR), and
MSCs
• Internet: Application Server.
The JAIN initiative
• Service Portability: Write Once,
Run Anywhere. Technology
development is currently con-
strained by proprietary interfaces.
This increases development cost,
time to market, and maintenance
requirements. With the JAIN ini-
tiative, proprietary interfaces are
reshaped to uniform Java inter-
Fig. 1 The JAIN APIs: an architectural overview
faces delivering truly portable
applications
• Network Convergence: (Integrated
Networks) Any Network. By deliver-
ing the facility to allow applications
and services to run on PSTN, packet
(eg, IP or ATM) and wireless net-
works, JAIN technology speeds net-
work convergence. As demand for
services over IP rises, new
economies of scale are possible as
well as more efficient management
and greater integration with IT
• Secure Network Access: By
Anyone! By enabling applications
residing outside the network to
directly access network resources
and devices to carry out specific
actions or functions, a new envi-
ronment is created for developers
and users. The market opportunity
for new services is huge when con-
trolled access is provided to the
available functionality and intelli-
gence inside the telecommunica-
tions networks.

A network layer
• Telecommunications: (Advanced)
Intelligent Networks (AIN/IN) or
Signalling System 7 (SS7) focused
on ISUP, INAP, and TCAP
• Wireless: SS7 with Mobile
Application Part (MAP) layer
• Internet or Packet: SIP, MGCP,
Megaco, and H.323.

A signalling layer
• Telecommunication: Signalling
Service Point (SSPs) or switches

SEP 01 TELECOMMUNICATIONS DEVELOPMENT ASIA – PACIFIC 79

 END-TO-END IP

Fig. 2 SIP and call control (courtesy

of dynamicsoft inc)

SIP, ISUP, call control, and JAIN

interfaces
JAIN SIP API
The adoption of Session Initiation Fig. 3 The JAIN SIP API (courtesy of dynamicsoft inc)
Protocol (SIP) as the de facto standard
for voice over the Internet, and for voice connection so the endpoint ini- the messages as events through the
communications services over packet tiates an INVITE; the proxy server provider/listener interfaces as shown
networks, has redefined network ele- returns a 100/TRYING. Upon resolv- in Fig. 3.
ments and distributed computing ing the address, the server returns an Since the JAIN SIP API is a com-
platforms into service creation tools, 180/RINGING, and then a 200/OK plete definition of the SIP standard,
application servers, SIP phones, inte- after the receiving party has accepted any SIP-based program may utilise
grated access devices, gateways and the call. The endpoint then sends an the JAIN SIP API as a Java standard
gateway controllers, SIP servers, SIP- ACK to the receiving party and the interface into any JAIN SIP certified
based services, SIP billing solutions, media stream is then set up. Upon stack. This means application servers,
developer toolkits, SIP testing tools, hanging up, a BYE is issued by one of SIP phones, gateways and gateway
SIP user agents, and SIP network the parties and the other party controllers, SIP servers, SIP-based ser-
management. The SIP-based network responds with a 200/OK. vices, SIP billing solutions, developer
has not only redefined the PSTN to The JAIN SIP API defines classes toolkits, SIP testing tools, SIP user
incorporate all the needed functional- for all the SIP headers and messages, agents, and SIP network management
ity of the PSTN, but also provided for and defines the interfaces for can all utilise the JAIN SIP API so as
the growth and extensibility of com- JavaBeans architecture processing of to be portable across and SIP stack
munications into media beyond
Fig. 4 JAIN SIP in the SIP network (courtesy of dynamicsoft inc)
voice. SIP is the specified underlying
protocol for the ‘4G’ all-IP mobile
networks of the future.
Because a SIP-based network with
location and server proxies allows
multiple vendors and multiple net-
works to interoperate, the growth of
SIP-based communications is limited
only by the media connections it has
to manage. This has created a large
community of developers writing SIP-
based communications applications,
proxy servers, user agents, tools, con-
trollers, etc.
The strength of SIP is basic call
control over the IP. As can be seen in
Fig. 2, an endpoint desires to set up a

80 TELECOMMUNICATIONS DEVELOPMENT ASIA – PACIFIC SEP 01


Fig. 5 ISUP call flow (courtesy of Ulticom Inc)
implementation.
Fig. 4 shows a typical SIP network
scenario where JAIN SIP interfaces
are utilised on proxy servers, media
gateways, and user clients.
Because the JAIN SIP API covers
far more than what is needed for a
user agent or client-based software,
the JAIN SIPLite API was developed
as a functional subset of JAIN SIP
API and basic call control process-
ing. JAIN SIPLite API is targeted at
user agents or clients with a small
footprint where the full suite of
JAIN SIP API class definitions is not
needed.
The SIP Servlets API extends the
HTTP Servlet definition to incorpo-
rate the processing of SIP messages, in
the same way an HTTP Servlet would
process an HTTP message. Like an
HTTP Servlet, the target platform for
SIP Servlets is a proxy server or an
application server. While SIP Servlets
may utilise the constructs of the JAIN
SIP API, the API constructs are simi-
lar to HTTP Servlet constructs.
JAIN ISUP API
This is analogous to ISUP in the
SEP 01
PSTN world. The call initiation cre-
ates a set-up request by the applica-
tion that is translated by ISUP into an
Initial Address Message (IAM) and
sent to the node at the remote end.
ISUP at the remote end on receiving
an IAM sends a set-up indication to
its user application. On receiving an
IAM for a voice circuit (identified by
its CIC), the circuit is marked busy.
The terminating application sends an
Alert Response to ISUP at the remote
node, which is translated by ISUP to
an Address Complete Message (ACM)
and sent to the originating node.
When the terminating user answers
the call, the application sitting over
ISUP sends a set-up response primi-
tive to it. ISUP sends this as an
Answer Message (ANM) to the origi-
nating node. The call is established.
The calling user then releases the call
by sending a Release Request primi-
tive to ISUP. Fig. 5 illustrates this
basic call flow.
Like the JAIN SIP API, the JAIN
ISUP API also defines all the mes-
sages, headers, and functionality to
pass the messages from the Java tech-
nology space into a vendor certified
TELECOMMUNICATIONS DEVELOPMENT ASIA – PACIFIC
END-TO-END IP
JAIN ISUP stack.
Contrast and compare: SIP and ISUP
Comparing ISUP to SIP, the IAM is
the same as the INVITE, the ACM is
same as the 100/TRYING, and the
ANM is the same as the 180/RING-
ING. The ACK in SIP has no similar
construct in ISUP and only provides a
level of comfort to the SIP network.
The REL is the same as the BYE, and
the RLC is the same as the 200/OK.
Both protocols serve the same
function: making a connection. One
may argue that SIP goes beyond voice;
however, simple additions and modi-
fications to ISUP – and all carriers and
countries have modified ISUP –
would extend ISUP to support any
media. Both protocols are extensible,
that is, they allow for the addition of
parameters outside the standard. Both
protocols are obtuse when naming of
their messages – a SIP INVITE is far
more meaningful than an ISUP Initial
Address Message; however, what do
the numbers 100, 180, and 200 mean
in SIP?
ISUP has stood the test of time and
is running in many networks world-
81
 END-TO-END IP
Fig. 6 JAIN ISUP
wide. It is robust and reliable. ISUP
also assumes responsibility over the
media connection, unlike SIP. A large
part of the ISUP primitives deals with
circuit management. In SIP, the
media is the responsibility of a gate-
way and the interface is MGCP or
Megaco. The problem with ISUP, and
SS7 in general, is the lack of interop-
erability between vendors and carri-
ers. This only exacerbates a drive
towards an open ISUP running over
IP. Since the world is going IP every-
where, SIP will replace ISUP as the
signalling protocol, and ISUP will be
relegated to the PSTN – which has set
the standard for quality and control.
Because SIP is an extension to the
HTTP protocol, SIP found immediate
acceptance in the IP community and
can readily run wherever HTTP runs.
This put SIP right into the public
domain where interoperability is a
foregone conclusion and all comput-
ing platforms could become SIP sig-
nalling platforms. Also the dynamic
nature of SIP to resolve address
opened up the possibilities for many
players to interoperate.
On the other hand, ISUP was
82
defined by several standards bodies
targeted at switching platforms inside
a very closed protected network.
Right from the start, there was no
incentive to interoperate between
ISUP-based platforms. ISUP relies on
a static point code configuration; SIP
relies on a proxy server that can be
updated at any point during opera-
tions. This makes SIP extensible to
any IP network and any vendor.
However worlds apart, SIP and
ISUP satisfy the functionality of set-
ting up and tearing down a
voice/media circuit. They both have
the built-in notion of a ringing
device at the endpoint and then mak-
ing and tearing down connections.
They are both designed for network
signalling with a protocol view of the
world. This view is where network
architecture defines network ele-
ments, messages, protocols, and
rules for interconnect. This view is
concerned with how connections are
made, and is not necessarily con-
cerned with who makes them and
why they are made.
Other parallels can be drawn
between the SIP network definition
TELECOMMUNICATIONS DEVELOPMENT ASIA – PACIFIC
and INAP where the protocol is built
more on functional elements as
opposed to pure messaging. The JAIN
initiative does not dictate one over the
other. The driving force behind the
JAIN initiative is to provide Java tech-
nology standards for communications
at all levels, whether SIP, ISUP, or
INAP. This empowers the network
architect to decide the virtues of one
over the other and then has the luxury
of utilizing the JAIN API where appro-
priate.
Where does call control fit in?
From the application side, there is
less concern as to how the connec-
tions are made and more emphasis on
why they are made and who needs
them where. The application develop-
er ends up bridging the gap between
the network domain and the service
domain. From the application writers
view, protocol interfaces are primi-
tives for passing data. The application
is more concerned with a model of
the network as it relates to other
computing elements such as databas-
es, management, user interfaces, etc.
From the application, call control
constructs like a CALL or CONNEC-
TION object with state information
and a full suite of interfaces are far
more meaningful than primitive mes-
sage constructs like an ISUP IAM or a
SIP INVITE message.
This does not diminish the need
for ISUP or SIP, but moves protocol
processing into a world where SIP and
ISUP are important network com-
modities for services. To the network
architect, a JAIN SIP or a JAIN ISUP
are invaluable; however, to an appli-
cation writer, the actual protocol is
less important than managing the ses-
sion or call. For the application
writer, the details of the protocol can
be buried under simple call control
primitives.
Instead of building and sending
JAIN ISUP or JAIN SIP primitive mes-
sages as part of a protocol, the Java
SEP 01

technology developer would rather
model the world around call control
objects such as a CALL, a CONNEC-
TION, or a PROVIDER, and then
actions are performed on these objects
such as CreateConnection or
RouteCall. A RouteCall in JAIN Call
Control (JCC) API may precipitate an
IAM in the PSTN to initiate a call, or
an INVITE in a SIP network to initi-
ate a session. The application writer
is none the wiser and is happy the call
was routed on any network.
JCC models the network as Java
objects and provides interfaces into
the objects through the JavaBeans
architecture event mechanism. In Fig.
7 the call is created from the provider,
and the connections are created from
the call. The interface into the objects
is through the JavaBeans synchronous
method calls and the receipt of Java
technology events.
Fig. 8 is a typical call flow from the
JCC application, through a JCC imple-
mentation, and the underlying ISUP
signalling – the ACM and ANM. The
ACM could readily be replaced with a
SIP 100/TRYING, and the ANM
replaced with an 180/RINGING.
The JAIN JCC API is structured
into the following three functional
areas (see Fig. 9):
• Elementary Call Control: JAIN
Call Processing (JCP) includes the
very basic facilities required for
initiating and answering calls. The
facilities offered by this package
are too elementary for many if not
most carrier-grade deployments.
However, JCP represents an impor-
tant conceptual cornerstone for
unifying the call control APIs
developed by the Java Telephony
API (JTAPI), JAIN and Parlay
expert groups
• Core Call Control: JAIN Call
Control (JCC) includes the facili-
ties required for observing, initiat-
ing, answering, processing and
manipulating calls, as well as to
invoke applications and return
SEP 01
Fig. 7 JCC provides interfaces through JavaBeans architecture event mechanism
(courtesy of Telcordia Technologies Inc)
results during call processing. A
call is understood to include a
multimedia, multi-party session
over the underlying integrated
(PSTN, packet and/or wireless)
network
• Extended Call Control: JAIN
Coordination And Transaction
(JCAT) includes facilities similar to
JCC, but extended to provide finer
granularity of call control. In partic-
ular, unlike JCC, JCAT enables all
common AIN applications as well
as other integrated voice/data and
next-generation services.
Applicability of JAIN APIs to
mobile networks
As 2G and 3G wireless technologies
distribute processing across the net-
work, ubiquitous standard Java tech-
nology computing is required to sup-
port new and updated wireless and
mobile services. Wireless carriers and
service providers are tasked with the
integration and harmonisation of all
the processes from the mobile station,
through the radio network, into the
switching network, and interfacing
into the Internet and packet net-
works. As shown in Fig. 10, wireless
networks’ basic domains are the
TELECOMMUNICATIONS DEVELOPMENT ASIA – PACIFIC
END-TO-END IP
handset (or mobile station), the Radio
Access Network (RAN), Network
Control and Management (MSCs,
HLRs, VLRs, etc), the enterprise, and
content and services.
In order to manage and bill for the
services in the wireless domains,
Operational or Business Support
Systems (OSS/BSS) are an integral part
of the overall solution. Where JAIN is
the development of Java standards
into communications, a similar initia-
tive is under way to develop Java stan-
dards for OSS/BSS, called OSS through
Java (OSS/J, for further information,
see java.sun.com/products/oss). The
integration of JAIN products with
OSS/J products is producing an archi-
tecture that is being defined by the
Java Technology for Service Providers
(JTSP, see java.sun.com/products/sp).
Java or JAIN architectures do not
address a complete wireless solution,
however, wherever there is a comput-
ing platform in the network, a Java
platform may run and JAIN interfaces
may be utilised. Fig. 11 illustrates the
areas defined for wireless across the
JAIN architecture. In the wireless
domain, the following sections
describe the application of JAIN and
Java interfaces.
83
 END-TO-END IP
Fig. 8 Typical call flow from a JCC application
Mobile station
In the future, almost all handsets will
be Java technology enabled, running
the Java 2 platform Micro Edition
(J2ME) platform. The handset will be
both voice and data enabled, which
means any number of services can
work in concert with the network.
Fig. 12 shows the various Java config-
Fig. 9 Functional relationship
between call control standards
84
urations for a handset.
In order to run Java applications on
a handset, the enabling technology
between the Java application and the
rest of the OS is a KVM – which is a
virtual machine that fits between 40
and 200 kilobytes — and there is a
Connected Limited Device
Configuration which defines Java pro-
files for limited devices, and there is
Mobile Information Devices Profile as
well, which is also a set of Java APIs.
Managing all of this is a JAM (Java
Application Manager) that manages a
lifecycle of Java applications that get
loaded onto the device as well as ele-
ments of security such as differentiat-
ing access from trusted and un-trust-
ed applications. MEXE (3GPP Mobile
device application Execution
Environment) has adopted Java and
TELECOMMUNICATIONS DEVELOPMENT ASIA – PACIFIC
CLDC/MIDP as a standard execution
environment for mobile devices.
For communications, a JTAPI
interface would provide connection
functionality, or SIPLite will treat the
handset as a SIP user agent. Where
JTAPI and SIPLite provide call control
functionality to the Java application
on the mobile station, further intelli-
gence is needed for security and priva-
cy issues. For example, if I desire to
meet an associate for lunch, but have
no idea where the associate is, yet I
have a mobile phone and my associ-
ate has a mobile phone, the network
knows where we are. However, I may
not want my mother-in-law who also
has a mobile phone, to find me. This
is a privacy issue.
Because this level of sophistica-
tion requires higher intelligence at
SEP 01

the handset and within the network,
a new industry is emerging focused
on availability management, trust,
and security. The JAIN Presence,
Availability and Management
(PAM) APIs and the JAIN Service
Provider APIs are tracking these
developments. The JAIN communi-
ty is working with leading vendors
as well as other standards bodies
(Parlay, ETSI, and the OSA) to
develop APIs around privacy, securi-
ty and availability. Standardisation
around this kind of interface
ensures portable services can be
flexible across all mobile devices
and wireless networks.
The Radio Access Network (RAN)
The RAN is primarily concerned with
routing voice traffic from the handset
into the network controlling ele-
ments that will eventually connect
the voice to the Public Switched
Telephony Network (PSTN). To pro-
mote roaming across wireless opera-
tors, the radio frequencies and sig-
nalling have been well defined
through GSM and IS41 standards. The
RAN devices include radio towers
and base station controllers. While
most of the devices within the RAN
are computing platforms, they usually
have well-defined static functions and
are not extensible by the user or the
operator. That is, little to no func-
tions or features are added to the
RAN after the wireless network is up
and running.
Because of the static nature of the
RAN, there has been no drive to
develop standard open interfaces
except those that would benefit the
wireless operator (GSM and IS41).
Since the wireless operator owned the
voice traffic from the handset into the
PSTN, there has been little motiva-
tion for the industry to promote and
enforce standards in RAN. A single
network equipment manufacture has
usually supplied the typical build out
of a RAN with proprietary interfaces
SEP 01
END-TO-END IP
Fig. 10 Wireless network’s basic domains
loosely based on GSM or IS41. for building scaleable RAN devices,
In 3G, the RAN is based on ATM such as radio network controllers.
for 3GPP’s Release 99 specification. Some of these vendors have started
Future releases will be based on IP to work collaboratively with the Java
and new standards need to be defined. technology community to extend
The IP RAN, as well as the underly- these platforms to provide even more
ing core network, will be based on availability. This benefits all users of
IPv6, thereby enabling many millions the platform by bringing carrier grade
of mobile Internet users to be secure- availability features to the enter-
ly addressed. This shift from closed prise/commercial J2EE platform.
proprietary interfaces and devices to
standard well defined interfaces and The network and the enterprise
network elements gives the wireless The JAIN MAP APIs define inter-
operator tremendous flexibility in the faces to acquire location (position),
RAN and also leads the RAN down Short Messaging Services (SMS),
an ‘open network’ path.
Since most RAN devices are com- Fig. 11 Areas defined for wireless
puting platforms, RAN vendors are across JAIN architecture
discovering Java technology allowing
them to increase productivity, robust-
ness, reliability, and time-to-market.
This has led to the recent development
of Java technology-based RAN devices
that include standard Java APIs, such
as the Java 2 Platform Enterprise
Edition (J2EE) platform APIs like EJB,
JMS, JNDI, and JAIN. For example,
they have discovered that EJB servers
can provide a highly available, hori-
zontally scaleable application platform
TELECOMMUNICATIONS DEVELOPMENT ASIA – PACIFIC 85
 END-TO-END IP
Fig. 12 Java handset configurations
Unstructured Supplementary Services
Data (USSD), Any Time Interrogation
(ATI) from an SS7 network. While the
original definition for JAIN MAP API
assumes an SS7 infrastructure, there is
nothing inherent in the API that would
require it be SS7 only; that is, the JAIN
MAP API could also run over IP.
The JAIN MAP APIs do not
define interfaces for all wireless
nodes such as MSCs, HLRs, BSCs,
etc. This was a conscious decision
by the JAIN MAP Expert Group, rea-
soning that any internal definition
would only benefit the wireless ser-
vice provider, not the developers
writing services. In other words,
defining standard interfaces for an
HLR, BSC or MSC does not bring
Fig. 13 Call flow of a location-based service
86
service portability, convergence or
open access to a wireless network.
Instead the APIs that look at what
would be most valuable to the enter-
prise would assist developers writing
services. For a wireless network,
location, status and passing mes-
sages to and from a handset are a
practical useful Java interface for the
developer of wireless services.
Most MSC functionality is being
filled with softswitch technology,
and softswitches are rapidly adopt-
ing JAIN JCC as the standard inter-
face. (See previous section).
Content and services
In the wireless arena, technology is
advancing and evolving from 2G
TELECOMMUNICATIONS DEVELOPMENT ASIA – PACIFIC
through HSCSD, GPRS and EDGE,
towards 3G, with each subsequent
advancement offering greater band-
width and hence the opportunity for
further enhanced content, services
and applications.
In order for operators to gain a
competitive advantage in the future
and to justify the high costs of 3G
licences, they need to be in a posi-
tion to offer a comprehensive set of
value-added services to generate new
revenues. To achieve this, innova-
tive telecommunication applications
may need to be developed outside
the operator’s domain. The introduc-
tion of the use of trusted third party
ISV applications that may often be
developed for specific niche markets
is clearly emerging as the way for-
ward. In adopting this approach, it is
essential for operators to maintain
the security and integrity of their
networks while providing trusted
third parties access to network
resources enabling them to develop
new services.
This has been a focus of the
Parlay organisation, wich is develop-
ing a series of API specifications in
Unified Modeling Language (UML).
The JAIN Service Provider APIs
(SPA) are providing the Java mapping
and realisation of Parlay’s technolo-
gy-independent specifications.
3GPP’s Open Services Architecture
(OSA) for 3G networks has also
adopted this model of third party
application development using the
operator’s network resources.
The JAIN SPA Mobility API is
based on the mobility specification
definition from the Parlay organisa-
tion. The API generates reports
based on location, handset status,
emergency services, and Camel-
based services. A sample call flow of
a location-based service through
JAIN SPA Mobility API, Parlay
objects, and JAIN MAP is shown in
Fig. 13.
In this example, the JAIN SPA
SEP 01

Fig. 14 JAIN SPA-based OSA wireless solution architecture
client requests a report to locate a
handset. When the request finds its
way through the Parlay gateway, the
4.1 processMSPosOperation (in Fig. 13)
is invoked into the JAIN MAP API.
End-to-end architecture
A sample architecture for a JAIN
SPA-based OSA wireless solution is
illustrated in Fig. 14.
The advantage that the JAIN APIs
bring to this architecture is the flexi-
bility to plug in any vendor’s JAIN
implementation without changing
any of the surrounding features. The
services run oblivious of underlying
network infrastructure. This allows
services to run in converged net-
works. The JAIN SPA and PAM
interfaces allow for open access into
a protected wireless network.
The JAIN architecture does not
dictate which APIs to use and
where. Rather, by building a robust
suite of interfaces developers have
more choices to build services at
either the network layer or the
application layer.
The Presence and Availability
Management (PAM) Forum has been
exploring this kind of intelligence
and is making proposals into Parlay
SEP 01
and the JAIN initiatives to develop
standard Java interfaces. PAM allows
networks to share authorised infor-
mation about subscribers’ identity,
presence and availability securely
across telephony and IP technologies.
Presence is the existence of a software
or hardware device through which
information can be communicated – a
cell phone, a PC, a PDA, etc.
Availability is the personal preferences
and policies an individual or enterprise
specifies for communication and con-
tent delivery services – when and how
to accept calls or content.
A possible PAM scenario could
incorporate Java technology agents
(beans) in the client and at the wire-
less service provider (SIP). Privacy
would be insured by a legal contract
signed between the client and SP.
While most of the contract is a fixed
document, another part of the con-
tract could be negotiated in an ad hoc
manner and be changed at the last
minute. For example, ‘Your boss
wants your location, shall I give it to
him?’ This kind of arrangement
requires a last minute decision that
has to be respected by the SP. This
means that the client and SP must log
all actions and changes to the con-
TELECOMMUNICATIONS DEVELOPMENT ASIA – PACIFIC
END-TO-END IP
tract, in case an audit is needed. The
Java technology agents also perform
the user interface on the client and at
the SP. After the Java technology
agents have established a legal basis
for privacy, control is passed on to
the service that is being requested.
So, if I want to meet my associate
for lunch, a simple request into my
handset kicks the Java technology
agents into high gear and requests
from both users that location infor-
mation is granted. (Although this may
seem redundant to the requesting
party, it adds an extra level of securi-
ty.) The Java technology agents log all
the information, making the neces-
sary modifications to the contract
with time stamps, and then pass the
information on to the services to per-
form the location and shortest path
algorithm.
The location of the devices is
determined through JAIN SPA
Mobility and/or JAIN MAP. Options
on this service may include the capa-
bility to confirm by voice or by send-
ing a short message. JAIN JCC, JAIN
SIP or JAIN ISUP can initiate a voice
call. A message can be sent via JAIN
MAP or JAIN SPA Mobility.
The JAIN architecture does not
prescribe or dictate the use of one API
over another or one device over
another, however the JAIN initiative
opens the opportunity for network
developers, service providers and
wireless operators to choose from an
open market of standard network ser-
vices and applications that are
portable across platforms, and pro-
vides converging open solutions to
heterogeneous networks.
JAIN; Java; Write Once, Run Anywhere;
JavaBeans; J2ME; JTEE; and EJB are registered
trademarks of Sun Microsystems, Inc.
Douglas Tait, Network Architect, Sun Microsystems
Inc, Palo Alto, California, USA
87