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-


2/20



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


3/20



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


4/20



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


5/20



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


6/20



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


7/20



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/20



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


9/20



13

Figure 6: Service side interfaces of Generic call control

Figure 7: Application side interfaces of Generic call control


10/20



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.


11/20



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


12/20



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.


13/20



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


14/20



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.


15/20



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


16/20



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


17/20



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


18/20



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.


19/20



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


20/20



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-

parlay api (thesis)

Documents