Download - Parlay API (Thesis)
-
8/8/2019 Parlay API (Thesis)
1/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
5
THEORY
The theory part of this thesis gives an insight into the concept of OSA/Parlay and
Teligents service platform P90/E.
OSA/Parlay
The following sections describe why a solution like OSA/Parlay is demanded, the pur-
poses and goals of OSA/Parlay and the organization behind the concept. It also gives an
overview of the logical architecture of OSA/Parlay and a description of the structure and
design of the application programming interfaces.
Traditional service creation within telecommunication
Services within telecommunication are traditionally required to be tailor-made for each
network providers network meaning that each network provider runs its own service
logic on top of his network. Applications and services are thus traditionally viewed as apart of the network provider domain [3]. A consequence of this is that network
providers are the only ones that can act as service providers and yet another
consequence is that services for one network are restricted to be used only within that
network. It is hence not possible for third party service developers to develop services
that can be used within an arbitrary telecommunication network. There is, however, an
increasing market for new creative, more advanced and comprehensive services within
telecommunication. Network providers are thus interested in finding means to be able to
offer these so-called value added services to attract new users and hence increase the
network usage [4].
Developing value added services in a fast, easy and not-too-costly manner requires
experience in the service development area. Network providers often lack the appro-priate knowledge to design these services and this introduces a need to cooperate with
service providers that possess experience in developing specific services. The services
would however still need to be tailor-made for the specific network and that can be
costly and time-consuming. The ideal solution would hence be if network providers
could take advantage of third party services, developed independently of underlying
network, and offer these to the users. An approach for making this possible is to
introduce a standardized interface between service logic and network domain which
allows service providers to develop services executable in different network providers
networks. The work within the Parlay Group has aimed to meet these criteria through
developing an object oriented application programming interface [4].
Parlay Group
The Parlay Group was founded in 1998 by five companies: BT, Microsoft, Nortel
Networks, Siemens, and Ulticom [6]. The Group started to develop a set of open and
standardized application programming interfaces (APIs) to make it more straight-
forward and faster to develop services and applications for telecommunication
networks. One goal was to make the APIs network independent to achieve easy porta-
-
8/8/2019 Parlay API (Thesis)
2/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
6
bility of applications between network technologies and to ensure that the network
could evolve without affecting already existing applications [3].
The work of the Parlay Group resulted in a specification release within one year of the
establishment and the development and maintenance of the APIs has continued with an
increasing number of participating member companies [3]. Today there are about 65
companies that form the not-for-profit Parlay Group and they represent both the IT and
telecommunication industries. The Group has, since the establishment, produced and
published a number of specifications where each new one builds on the last to maintain
backward compatibility. Work is also done to enhance the existing specifications and to
incorporate new requirements based on feedback from the industry [2].
Joint Working Group
The Parlay Group collaborates with other standard organizations working with similar
specifications to avoid development and publishing of duplicate or ambiguous specifi-
cations in the industry [2]. An example of this collaboration is the joint work between the
Parlay Group, the Third Generation Partnership Program (3GPP) and the EuropeanTelecommunication Standards Institute [1].
Parlay, 3GPP and ETSI decided to cooperate when they realized that they were working
towards the same goals, i.e. to create a set of application programming interfaces for ser-
vice development within telecommunication. 3GPP and ETSI were developing appli-
cation programming interfaces under the name OSA, an acronym for Open Service
Access, with intention to facilitate service development within third generation mobile
networks. The Parlay Group on the other hand aimed to develop a set of APIs that were
network independent and could be used for different types of networks. In spite of the
different focus areas there was a decision to collaborate and the organizations formed
the Joint Working Group where much of the technical work with the now called
OSA/Parlay APIs is done [2][3].
-
8/8/2019 Parlay API (Thesis)
3/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
7
OSA/Parlay Application Programming Interfaces
The following sections describe the conditions of OSA/Parlay and the latest version of
OSA/Parlay, version 4.
What is OSA/Parlay
An application programming interface (API) provides application developers with inter-
face classes and methods that can be used to apply certain functionality to an application
without needing to implement the underlying logic for the functionality. OSA/Parlay is
an open and standardized set of application programming interfaces designed to
simplify and speed up the creation of new services
within telecommunication. OSA/Parlay enables
service providers to develop value added network
services through using the same technologies used
for fast application development within IT, such as
open APIs, distributed computing, Java and Web
Services. The API is furthermore developed to openthe network and expose network functionality
through serving as middleware between network
and service applications (figure 1). The application
logic is thus separated from the network
functionality at the same time as service providers
outside the network domain are allowed to access
core network functionality and resources in a
controlled way without compromising the network
security [2][3].
The interfaces of OSA/Parlay are designed to be technology and network independentand can be used for mobile, fixed and next-generation networks. Specific network imple-
mentations and underlying protocols are made transparent to the applications to shield
them from network complexity [7]. The network independence makes it possible to write
applications that can run on a variety of underlying protocols and it allows that
applications are ported from one network to another without inflicting the performance
of the application [2].
Another consequence of the network independence is that services can be developed by
software developers skilled in other areas than telecommunication. This is possible since
the developers are not required to have any prior knowledge about telecom protocols
and network technology to be able to use the API. A consequence is that developers can
focus on implementing services rather than focusing on interoperability between
different network providers [4].Using OSA/Parlay also provides additional flexibility in
service development since service providers can use the same set of interface classes and
methods for multiple manufactures platforms, i.e. assuming the platforms support the
API [2].
To assure that OSA/Parlay can be used by a large developer community it is based on
open standards like CORBA, UML, Java and Web Services such as SOAP, XML and
Figure 1: OSA /Parlay middleware
-
8/8/2019 Parlay API (Thesis)
4/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
8
WSDL. OSA/Parlay furthermore includes support for implementation in a variety of
programming languages, e.g. C, C++ and Java [2].
Logical Architecture
The logical architecture of OSA/Parlay includes the following logical entities
according to Moerdjik and Klostermann (figure 2): Service Capability Features
Service Capability Servers
Applications
Application servers
Framework
Core network elements
Figure 2: Logical architecture
The OSA/Parlay Service Capability Features specifies methods for different types ofservices, such as messaging, user interaction and call control, towards applications. The
Service Capability Features (SCFs) are thus the entities that interact with core network
elements and give access to network functionality. Each SCF specifies a number of
interface classes that are distinguished as application side interfaces or service side inter-
faces [7].
-
8/8/2019 Parlay API (Thesis)
5/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
9
The Service Capability Server is a logical entity that acts as a proxy or a gateway to the
core network and all OSA/Parlay interaction between application and network must
pass through this gateway. It implements the service side interfaces of one or more SCFs
and the network functionality is thus offered to applications through the Service
Capability Server and the interfaces in the Service Capability Features [3].
Two other important entities in OSA/Parlays logical architecture are applications and
application servers. Applications implement the application side of the Service Capa-
bility Features and are assumed to run on an application server [2]. The application
servers may be located in the same domain as the core network but may as well be
placed outside the trusted domain. The communication between application and Service
Capability Server is realized with standard IT middleware infrastructure, e.g. CORBA
[3].
The framework is the last entity and it is an essential part of the network security and it
can either be located in the SCS or be detached. It manages registration of new Service
Capability Features and it regulates the access to the services and thereby controls the
access to network resources. The framework is designed to solve security andavailability problems that arise when the network is opened up for use from un-trusted
domains. The framework is also a means to avoid that the communication infrastructure
is exposed to unauthorized use [2] [3].
OSA/Parlay - version 4.1
The OSA/Parlay specifications are published by Parlay, ETSI and 3GPP and the latest
release, version 4.1, can be found at Parlays and ETSIs website [1][5].
Version 4.1 consists of fourteen main parts that includes common data definitions,
framework definition and specifications for a set of Service Capability Features and an
enumeration of the parts of version 4.1 can be found in Annex A. The framework con-trols security and registration of new services (i.e. Service Capability Features). It also
manages and controls the access to registered services and to network functionality. The
Service Capability Features (SCFs) offer interfaces to the network elements and there are
specifications for a total of fourteen different SCFs within version 4.1. Each SCF specify
interfaces that differ with respect to the functionality they support towards the
application. There are SCFs for messaging, user interaction, call control and charging to
mention a few [7].
Each part of the API is defined in UML for technology independence and the
specifications are structured with sequence diagrams, class diagrams, interface class
specifications and state transition diagrams. The sequence diagrams show examples of
the field of application for the interfaces and furthermore an example of how the inter-
faces may be implemented. The class diagrams represent the relationship between the
interfaces in a SCF and the interface specifications give a detailed description regarding
methods, parameters and types for each interface included in the class description. The
state transition diagram offers a presentation of the different states that an object that
implements the interface may be in. In addition to the UML representation of the API
there is also a representation in IDL, WSDL and JAIN. IDL, WSDL and JAIN differ with
-
8/8/2019 Parlay API (Thesis)
6/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
10
respect to which distributing technology they realize. IDL is the CORBA realization
whereas WSDL is the SOAP/HTTP realization. JAIN references the API in Java and
thereby specifies a Java local API technology realization of OSA/Parlay [7].
Three important entities within the concept of OSA/Parlay are framework, applications
and Service Capability Features and the communication between these entities is
supported by the following interface types, pictured in figure 3:
A. Interface classes between
application and framework to
negotiate and control which
network services the application
may use.
B. Interface classes between
application and Service Capability
Features (SCF) to access the
functionality that the SCF provides.
C. Interface classes between
framework and Service Capability
Features to register new services.
A further classification is done within OSA/Parlay version 4.1 regarding the interface
methods. Two types of methods are distinguished, synchronous and asynchronous. The
synchronous methods are used to fetch data and to create new object instances. These
methods do not require communication with other nodes in the network. Asynchronous
methods, on the other hand, do require communication with other network elements.
The methods are made asynchronous to avoid that applications are blocked while wait-
ing for the network to return result or error messages for a requested service [7].
Service Capability Features
OSA/Parlay specifies a set (fourteen in version 4.1) of Service Capability Features that
provides interfaces to different network capabilities such as messaging, call control,
charging and mobility. Each SCF defines a set of interfaces and a separation is made
between application side interfaces and service side interfaces, as pictured in figure 4 on
next page. The service side interfaces are intended to be implemented in the Service
Capability Server and are hence located in the network domain. The application side
interfaces on the other hand are intended for implementation in an application [7].
Each interface class consists of a set of methods and for some of the interfaces there areminimum requirements regarding methods that must be implemented when providing
support for a certain Service Capability Feature [7].
Figure 3: Interfaces
-
8/8/2019 Parlay API (Thesis)
7/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
11
Figure 4: Service Capability Feature interfaces
OSA/Parlay Call Control
OSA/Parlay provides a number of APIs for call control related services. The four de-
tached Service Capability Features for call control are Generic Call Control, Multi-Party
Call Control, Multi-Media Call Control and Conference Call. Generic Call Control
provides basic call control services such as setting up, routing and releasing calls with at
most two active parties. Multi-Party Call Control enhances the basic functionality in
Generic Call Control with support for more than two attached call parties. The functio-
nality of Multi-Party Call Control is then enhanced by Multi-Media Call Control that
adds multimedia capabilities such as media channel control. The final SCF within the
Call Control family is Conference Call Control and it enhances Multi-Media Call Control
with routines for establishing conference calls [4][7].
The OSA/Parlay specifications define a call model that the call control Service Capability
Features are based on. The call model includes the following entities, pictured in figure5:
Call objects: represent the relation between a number of parties.
Call legs: represent a logical association between a call and an address and hence
represent the parties in a call.
Addresses: logical representation of a party in a call, e.g. a phone number.
Terminals: the end-point of the signaling for a party.
A call is established through creating and attaching one call leg for each party in the call.
If there is two or more call legs attached to a call it means that there is a connection
between the parties and that they can speak to each other [7].
-
8/8/2019 Parlay API (Thesis)
8/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
12
Figure 5: Call model entities
Generic call control Service Capability Feature
The Generic call control Service Capability Feature defines interfaces for implementation
of basic call control services for creating and routing calls through the network. The
management of calls in Generic call control is restricted since it only implements a subsetof the call model described in the section above (OSA/Parlay call control). The restriction
lies in that there is no way to explicitly access and manipulate the call legs (call parties)
and the calls are restricted to managing at most two active call legs at the same time. It is
hence only possible to create a basic call between an originating and a terminating party
when using Generic call control [7].
Generic call control includes four interface classes, two for service side implementation
and two for implementation in applications. The service side interfaces are called
IpCallControlManager and IpCall and the application side interfaces are
IpAppCallControlManager and IpAppCall. As mentioned earlier, there is a UML class
diagram representation of the relationship between interfaces in a Service Capability
Feature. Figure 6 and 7 (on next page) are found in the OSA/Parlay specification version
4.1 and they picture the class diagrams for the service side respectively the application
side interfaces of Generic call control. IpService is a base interface class for every service
interface and it provides two methods for setting callback references to an application.
The callback references are used when the service side wishes to communicate with an
application. IpInterface is an empty (i.e. it does not define any methods) base interface
class that every interface in the API as well as IpService inherits from [7].
-
8/8/2019 Parlay API (Thesis)
9/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
13
Figure 6: Service side interfaces of Generic call control
Figure 7: Application side interfaces of Generic call control
-
8/8/2019 Parlay API (Thesis)
10/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
14
IpCallControlManager and IpCall provide methods to manage basic call control services
in the network. IpCallControlManager is the service manager for Generic call control
and it controls all active calls. It provides methods to create call objects and to enable and
disable monitoring for call-related events in the network. This means that an application
can request to be notified when a call meets certain criteria, such as originating address
or call state. IpCall, on the other hand, offers functionality for manipulating call objects,
e.g. call routing and call supervision. IpCall does also support methods for requesting
call information and functionality for terminating calls in the network. The application
side interfaces, IpAppCallControlManager and IpAppCall, are implemented in the
application to handle responses and reports from the network, i.e.
IpCallControlManager and IpCall communicate with the application through the call-
back methods that these interface classes provide [4][7].
Teligent P90/E
Teligent is a solution provider within telecommunication that has specialized in valueadded services. The solutions are based on a network independent platform named
P90/E that has a system architecture designed for implementation of value added ser-
vices. Teligent has not specialized with a specific type of services and a result is that the
service portfolio ranges from basic services, e.g. number translation, to advanced ser-
vices such as speech recognition and voice mail. It is furthermore possible to add new or
combine services within the platform. This is achieved through platform configuration
and it is hence possible to provide a tailor-made service solution according to customer
requirements. The platform is furthermore based on an open standard architecture that
allows services to be developed either by Teligent or by third party service developers.
Different types of messaging (SMS, MMS etc.) and payment solutions such as collect call
are examples of services that Teligent offers and that works for both fixed and mobile
networks [9].
Figure 8 (on page 15) is found at Teligents website, www.teligent.se, and gives an
overview of the P90/E concept and the platform structure.
-
8/8/2019 Parlay API (Thesis)
11/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
15
Figure 8: Teligent P90/E concept
The picture shows that P90/E is located on top of a UNIX operating system and that the
platform offers services within Intelligent Networks (IN)/3G and messaging. It further-
more shows that it is possible to develop service solutions that match specific customer
requirements by using Teligents service creation tool [11]. An implementation of
OSA/Parlay in the platform would result in an additional way to develop services, i.e.
through using the OSA/Parlay Application Programming Interface.
Two important concepts within the P90/E structure are components and transactions.
Services are built with components and transactions are used for communication withinthe system. The following sections will describe the concepts closer.
P90/E transactions
Teligent P90/E is a system which manages communication between different parts of the
system through sending transactions, i.e. pieces of data structured according to a
protocol. All communication between different parts is managed with transactions and
transactions are hence the only way for entities within the platform to interact with each
other. The transactions (e.g. a function request) are sent from one part of the system to
another part that executes the request and then a reply is returned. The reply is also a
transaction that indicates whether the requested function was executed successfully ornot and the reply may contain possible reply data. The transaction reply is detached
from the transaction request since the transaction protocol is designed to be asyn-
chronous. This means that a program that issues a function request can continue its work
and will not be blocked waiting for a reply [10].
-
8/8/2019 Parlay API (Thesis)
12/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
16
P90/E components
Teligent P90/E has a modular design that is based on components. The components are
software programs that are developed to provide functionality, e.g. operations per-
formed in the telephone network. A component can act as client, when requesting
functionality from other parts of the P90/E, and as a server when it is executing functions
that other components have requested [10].
The platform includes a number of different components. There are kernel components,
application components and support processes. It is the kernel components that together
form the base platform and they are required to be present in each platform con-
figuration. There is also an extensive component library that includes application
components to support a variety of application functionality. There is for example app-
lication components for different types of call control, database access etc. Finally, the
support processes manages the P90/E environment concerning hardware and operating
system [10].
The components were originally built in C but today there is also a C++-shell that makes
it possible to develop components in C++ as well. The C++ library is offered in form of an
application programming interface (API) that includes classes and functions for imple-
menting a comprehensive component and for managing and sending transactions.
-
8/8/2019 Parlay API (Thesis)
13/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
17
IMPLEMENTATION OF OSA/PARLAY IN P90/E
Analysis
The analysis part aimed to provide a foundation for the subsequent parts.
Requirements
The given starting-points before beginning to work with this masters project were that
OSA/Parlay should be evaluated through implementation in a transaction-based service
platform named P90/E. The work was to be based on three main questions:
How can OSA/Parlay be developed and implemented in P90/E to make it
possible for applications located in an arbitrary application server to use the
interfaces for executing services provided by the platform?
Is it possible to find a model for dynamic implementation of Service Capability
Features? Is there any difference in performance when executing the functionality of the
OSA/Parlay implementation compared to executing the same service directly in
P90/E?
It was further decided that the implementation should support the following
functionality:
Make call: an application should be able to initiate a call.
Accept call: there is support for notifying an application about a call in the
network and the application should be able to accept the call, i.e. gain control
over the call.
Reject call: there is support for notifying an application about a call in the
network and the application should be able to reject the call.
Answer call: there is support for notifying an application about a call in the
network and the application should be able to accept and answer the call, i.e.
gain control over the call and be connected to the calling party.
Redirect call: an application should be able to redirect a call from one party to
another.
Make call refers to functionality that makes it possible for an application to initiate a call
between two parties by defining two addresses (phone numbers) between which the call
should be arranged. The appropriate OSA/Parlay methods that handle the underlyingnetwork traffic to support that a call is set up should thus be invoked. That is, the
application should have the ability to request that a conversation between two persons
over the telephone network is set up.Accept call and reject call on the other hand refers to
functionality for call detection and notification forwarding. This means that it should be
possible to detect calls in the network and send notifications to OSA/Parlay supporting
applications. The implementation should further be able to handle that the application
either accepts or rejects the call when receiving a notification. An accepted call means
-
8/8/2019 Parlay API (Thesis)
14/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
18
that the application agrees to request that the call is directed to a certain destination
address. An example can be that a call from person A is detected in the network
whereupon the application is notified. If the application accepts the call from A then it
sends out a request that the call should be routed to the address of person B which
makes it possible for the parties to talk to each other. However, it is also possible for the
application to reject a call that it does not approve of. This could for example occur if theapplication is restricted to only allow directing request for addresses (phone numbers) in
a certain interval. The functionality of answer call also refers to call detection and
notification forwarding to the application but in this case it is considered that the
application user, e.g. a call attendant, answers the call. The difference between accept call
and answer call is thus that accept call can be viewed as a call that arrives to an exchange
and after that are rerouted. The flow of events takes place without the calling partys
awareness. Answer call on the other hand can be viewed as the case where a call
attendant answers the call and talks to the calling party before rerouting the call to a
destination address.
Finally we have redirect call which concerns functionality for requesting that a call is
redirected from one address to another. This type of functionality is of interest when
routing to an address is unsuccessful for some reason. The called party can for example
be busy or not available and the application (call attendant at the switchboard) then has
the choice to redirect the call to another address, for example to a voice-mail or to an
alternative address. A scenario could be that person A calls company C to talk to
someone at the sales department. A is directed by the call attendant to person B but B is
occupied in a meeting and there is thus a need to redirect A to another address. The
application redirects A to person D who answers the call and A can finally present his
matter to someone at the sales department.
After settling the functionality requirements above the work continued with an analysis
of the problem domain which included gathering and reading material aboutOSA/Parlay. The purpose was to obtain an overall understanding for the structure of
OSA/Parlay and acquire a deeper understanding for the call control parts of the
application programming interface. Such an understanding was necessary to be able to
make design choices concerning appropriate interfaces for implementation in P90/E.
There was also a need to understand the P90/E platform environment including
components and transactions and this was accomplished through reading P90/E
manuals and through discussing the platform with Teligent employees.
The analysis resulted in making the following decisions for the work to come:
OSA/Parlay Generic call control was chosen over Multi-party call control for
implementation in P90/E.
C++ was chosen as development language.
CORBA was chosen for managing communication between application and
P90/E component.
A call handling component within the P90/E component library was chosen to
handle communication between P90/E and the telecommunication network.
The OSA/Parlay interfaces should be implemented as a new P90/E component.
-
8/8/2019 Parlay API (Thesis)
15/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
19
The decision to choose Generic call control was based on the fact that it is the base for
call control and is described with a less complex call model (that excludes call legs) than
Multi-party call control. It also appeared to be a correct choice considering that the
functionality requirements did not require support for more than two call legs at the
same time. The choice of implementing Generic call control implied that the interfaces of
interest were IpCallControlManager and IpCall. The application side interfaces, IpApp-CallControlManager and IpAppCall, also needed consideration for the development of
the test application. The main focus was however on implementing the service side
interfaces as a component in P90/E and most effort was concerned with that area.
The decision to use CORBA for communication was a requirement from Teligent and so
was the choice to develop the Generic call control feature in C++. This choice was made
over Java since Teligent offers an application programming interface for development of
P90/E components in C++. There was some discussion regarding which call handling
component to configure the P90/E with but the final decision was to use a component
with Intelligent Network Application Protocol (INAP) abilities since it would not require
installation of any additional hardware. It should be noticed that the INAP-component is
Teligent property and specific details about the design or supported functionality therein
is confidential information. There will therefore not be any further discussion about
specific details concerning that component.
System overview
The requirements that were determined to apply for this project was the foundation for
establishing an overall system design. The system design in figure 9 was based on the
conditions for OSA/Parlay in general and the conditions for OSA/Parlay call control and
Teligent P90/E particularly. The conceptual system consisted of a Service Capability
Server with an OSA/Parlay Framework, CORBA support, a number of OSA/Parlay
Service Capability Features and some P90/E components.
Figure 9: Original system design
-
8/8/2019 Parlay API (Thesis)
16/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
20
The Service Capability Server for this project was the P90/E platform and it was within
the platform that the other entities were developed [2][3]. CORBA was used for
communication with applications and that allowed applications to be located outside the
platform domain. The possibility to use CORBA was offered directly by OSA/Parlay in
form of IDL specifications [7]. Regarding the Framework, the intention was that it would
be installed and available in the platform once the implementation started. This washowever not the case due to delays in the purchase and installation process. The
Framework was there-
fore not considered du-
ring this masters project
although system inte-
gration with the Frame-
work was originally in-
tended. When it comes
to the Service Capability
Features (SCFs) and the
P90/E components, dif-ferent SCFs may require
that the platform is con-
figured with different
components. A user
interaction SCF may for
example require a different configuration than a call control SCF. This masters project
was concerned with the latter and that opened up the configuration possibilities since
there are a number of available call control components in the P90/E component library
[10]. The decision to implement Generic call control required that the platform was
configured with P90/E kernel components and an additional call control component,
which for this project was an INAP-communicating component. The reasoning above
lead to some restrictions and modifications of the original system design and the
simplified design that was used throughout the project is found in figure 10.
Use cases
The work continued with defining use cases and a use case diagram to represent the
functional requirements aligned with the functionality specified in the Generic call
control SCF.
The OSA/Parlay specification for the Generic call control SCF was studied in addition to
the functionality requirements demanded by Teligent to come up with a use case
representation. The result was that a system, two actors and eight use cases were definedas pictured in figure 11 (on page 21). The system was defined to be the OSA/Parlay
component implementation in P90/E. The actors were distinguished to be an application
outside the P90/E and a call control component within the platform.
The application communicates with the OSA/Parlay component through the service side
interfaces of Generic call control, IpCallControlManager and IpCall, while the reverse
communication is managed through application references and the application side
Figure 10: Current system design
-
8/8/2019 Parlay API (Thesis)
17/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
21
interfaces, IpAppCallControlManager and IpAppCall. The second actor, the call control
component, interacts with the OSA/Parlay component through P90/E transactions.
The following use cases were defined:
Create call the application requests that a new call object is created
Route request the application requests that a call is routed to a specific address Call notification the application enables and disables call notifications
Call event the call control component notifies the OSA/Parlay component about
call related events in the network
De-assign call the application relinquish the control of the call
Release call the application requests termination of a call
Call status the call control component forwards a network reply regarding an
earlier route request to the OSA/Parlay component
Call ended the call control component informs the OSA/Parlay component that
the call was terminated in the network
Figure 11: Use case diagram
Before describing the use cases a bit closer let us straighten out the conditions for them.The first thing to remember when looking at the use cases is that the functionality
requirements implied that it was necessary for the OSA/Parlay component to support
that calls were created, routed to a specific address and terminated. In fact, two main
scenarios were distinguished from the functionality requirements. The first scenario
involved application initiated calls whereas the other one concerned call detection in the
network and notification forwarding. These scenarios will be recurring throughout the
rest of the text and the type of functionality they involve is supported within
-
8/8/2019 Parlay API (Thesis)
18/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
22
OSA/Parlays specification for Generic call control. It is thus possible, through combining
the different use cases, to represent both scenarios.
The second thing to remember when looking at the use cases is that Generic call control
is one of the call control APIs of OSA/Parlay and this implied that the implementation in
P90/E had to be designed from the call model that is defined within OSA/Parlay. The call
model includes the following entities: calls, call legs, call addresses and terminals [7].
The use cases described below involve creation and manipulation of these entities. For a
description of the call model concept refer to section OSA/Parlay Call Control and Generic
call control Service Capability Feature (on page 11 and 12).
Create call
Create call refers to when the OSA/Parlay component is requested to create a new call
object. The call creation request can originate either from the application or from the call
control component. The latter is the case when a call is detected in the network and a
notification is forwarded to the OSA/Parlay component. A call object needs to be created
in this case to give the incoming call an OSA/Parlay representation and in that way allowthat a second party may be connected to the calling party. This use case is a logical step
defined by the OSA/Parlay standard. It is managed completely internal by the service
side implementation of Generic call control, i.e. the OSA/Parlay P90/E component, and
no communication will take place with other parts of the P90/E or the tele-
communication network.
Route request
Route request involves routing a call request to an address which in other words means
requesting an attempt to attach a call leg to a call (i.e. connect a call party to a call). A
prerequisite for this use case is that there is an existing call that allows that call legs are
attached to it. The call object will however not allow that a call leg is attached if thenumber of already attached legs exceeds two since Generic call control only provides
support for two active call legs per call.
The request to route a call to a destination address is initiated from the application but
the request also requires that the OSA/Parlay component forwards the request to the
P90/E call control component. The consequence of executing this use case should be that
the call control component initiates call routing in the network and the desired result is
that it starts ringing at the destination.
Call notification
OSA/Parlay offers support for applications to be notified when a call or a call relatedevent occurs in the network. According to OSA/Parlay this requires that the application
enables call notifications, otherwise it will not be notified. An application can thus
choose to enable (subscribe to) call notifications and specify the criteria and events for
which it is interested to be notified. This and the possibility to disable (unsubscribe to)
call notifications that once were enabled is what Call notification is concerned with.
-
8/8/2019 Parlay API (Thesis)
19/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
23
Call event
Call event is concerned with how the call control component informs the OSA/Parlay
component that a call or a call related events has been detected in the network. The
result should be that the OSA/Parlay component investigates whether there are any
enabled notifications among the applications. If that is the case then the OSA/Parlay
component should forward the event to the application in question.
De-assign call
The application has the opportunity to (in OSA/Parlay language) de-assign an active call.
This means that the application instructs the OSA/Parlay component that it is no longer
interested in controlling the call. Once the application has de-assigned the call then the
application is not further justified to manipulate or use the call to initiate route requests
according to the OSA/Parlay specifications [7]. De-assigning a call will, however, not
affect an ongoing call in the network between two parties and the call will thus continue
until one of the call parties terminate the call.
Release call
Release call should be executed when an application wants to terminate a call.
Termination of a call means that the application will no longer be able to control the call
and that the call will seize to exist in the network. Any attached call legs will be
discarded and if there is an ongoing call between two parties then the connection will be
torn down and it will not be possible for the parties to continue their conversation (as
defined within OSA/Parlay [7]).
Call status
OSA/Parlay methods that require communication between different parts of the P90/E
and the telecommunication network are asynchronous. This means that the thread thatexecutes the program is not locked after requesting network communication until a
reply from the network returns. The Call status use case deals with the replies that are
returned from the network. The call control component initiates the use case by for-
warding the replies that are achieved from the network. If the reply for example is a
reply to an earlier route request then the reply can be an indication on whether the
routing was successful and if the party was busy or answered the call. The event can
then be forwarded from the OSA/Parlay component to the application.
Call ended
The call control component should notify the OSA/Parlay component if a call is
terminated in the network for some reason. The information should then be forwarded
to the application which in turn is expected, according to OSA/Parlay, to de-assign the
call.
Combined use case functionality
Through combining the above use cases the two scenarios mentioned earlier can be
established. The scenarios concerns application initiated calls and detection of calls in the
-
8/8/2019 Parlay API (Thesis)
20/20
Implementation of an Application Programming Interface in a Service Platform Linda Doktr
An evaluation of the Telecommunication API of OSA/Parlay
24
network. This section gives an insight into how the use cases may be combined to form
realistic call scenarios.
The use cases allow an application to request that a call between two parties is set-up.
According to the call model that OSA/Parlay specifies this requires that a call object is
created for which it is possible to attach two separate call legs. The leg attachment is
done automatically when using Generic call control since there is no explicit access to the
call legs [7]. The call creation functionality is supported by the Create call use case. After
call creation it is necessary to make a call request for each party to be able to connect
them to the call, i.e. attach the call legs. The call request means that it starts ringing at a
terminal, e.g. a mobile phone. This is triggered by Route request and the reply from the
network concerning whether the call attempt was successful or not is managed by the
Call status use case. Once both call parties has been successfully reached, i.e. they have
answered the call, then there is a connection between the parties and a conversation can
take place.
The application can relinquish the control over the call in two separate ways. It can
either request that the call should be terminated in the network which means that thecall will no longer exist and the parties will be disconnected. The other choice is that the
application relinquishes the control but allow the call to continue to exist in the network
which means that an ongoing call between two parties can continue as well. This
functionality is the area of concern for De-assign call respectively Release call. It is also
possible that the call is terminated in the network due to network failure or a similar
event and this case is handled by the Call ended use case. Finally it is also possible for
applications to subscribe to notifications concerning certain events that may occur in the
network. This and the unsubscribe case are made possible through the Call notification
use case. Call notification subscription is tied to the Call event use case which handles
forwarded information about a certain call event.
Design
The design phase involved developing a design and structure for the implementation to
be built upon.
Translation between OSA/Parlay and P90/E transactions
The OSA/Parlay application programming interface is designed to be suitable for all
types of telecommunication networks and protocols. This means that the interfaces in-
cluding methods, parameters and types are made general and that there are no custom-
made solutions for specific protocols and networks. The consequence is that it is
necessary to perform a translation between OSA/Parlay and the network protocol and
vice versa. This OSA/Parlay-to-network protocol translation is unnecessary for imple-
mentation in P90/E since the P90/E call control component are configured to handle
network communication and transaction-to-network protocol translation. Instead it is
necessary to perform a translation between OSA/Parlay and Teligent P90/E transactions
so that the OSA/Parlay component is able to send the correct transactions with the
appropriate parameters to the call control component to use for network communi-