White Paper

Knowledge Management

Building Powerful Applications

The OSA Application Server

w w w. f l ex t ro n i c s s o ft ware . co m
 White Paper

Copyright Information
© 2005 Flextronics Software Systems Ltd. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means, electronic or otherwise, including photocopying, reprinting or
recording, for any purpose, without the express written permission of Flextronics Software Systems Ltd.

Disclaimer
Information in this document is subject to change without notice and should not be construed as a commitment on the part of Flextronics Software
Systems. Flextronics Software Systems does not assume any responsibility or make any warranty against errors that may appear in this document and
disclaims any implied warranty of merchantability or fitness for a particular purpose.

Trademarks
All other company, brand, product or service names mentioned herein are the trademarks or registered trademarks of their respective owners.

Flextronics Software Systems Ltd.

Plot 31, Electronic City, Sector 18,
Gurgaon - 122015
Haryana (INDIA)
Tel: +91-124-2346666/2455555
Fax: +91-124-2342415/2342810
e-mail: info@flextronicssoftware.com
Visit us at: http://www.flextronicssoftware.com

i n fo. f l ex t ro n i c s s o ftware . co m
 White Paper

Th e O SA A p p l i c at i o n S e rv e r

Contents

1. Introduction .....................................................................................................................................................................................4
1.1 The evolution of wireless .....................................................................................................................................................................................................................................................4

2. What is B2BUA and why is B2BUA important? ......................................................................................................................5

3. What is OSA? .....................................................................................................................................................................................6

3.1 Why OSA? .................................................................................................................................................................................................................................................................................6

4. Where does the OSA Application Server fit in? .....................................................................................................................7

5. Why the OSA Application Server is a carrier grade solution .................................................................................8

5.1 Grow as demand grows .....................................................................................................................................................................................................................................................8
5.2 Round the clock availability .............................................................................................................................................................................................................................................8
5.3 Overload protection control ............................................................................................................................................................................................................................................9
5.4 Configurability ......................................................................................................................................................................................................................................................................9
5.5 Distributed versus monolithic architecture ............................................................................................................................................................................................... ...............9

6. Salient features .............................................................................................................................................................................10

7. Making advanced applications a reality ...............................................................................................................................11

8. Simple call-flow for call queue application .......................................................................................................................12

8.1 Routing to one of the free operators ............................................................................................................................................................................................................................12
8.2 Connecting to annoucement server, when free operator is not available .....................................................................................................................................................12
8.3 Connecting a queued subscriber to a free operator ...............................................................................................................................................................................................12

9. Conclusion ......................................................................................................................................................................................13

w w w. . f l ex t ro n i c s s o ft ware . co m
 White Paper

Introduction

1. Introduction
As application developers invest in building such value-added services,
The Voice over Internet Protocol (VoIP) space has witnessed high velocity they need a robust software infrastructure for lower layers. Session
growth in the past year - a trend that is likely to continue as the quality Initiation Protocol (SIP), which has been adopted as the standard by
and reliability of VoIP technology improves and more companies bodies like 3GPP, is thus becoming the ubiquitous network protocol and
integrate the technology into their infrastructure. Experts have reported is poised to gradually replace the current SS7 based platform for service
rapid growth in all areas of VoIP technology including adoption, creation. Flextronics Software Systems' (FSS) OSA-compliant SIP
investment and revenue. In fact, Frost & Sullivan predicts that VoIP will Application Server with B2BUA functionality enables application
account for almost 75 percent of global voice services by 2007. developers to concentrate on what they do best - developing
applications - while it takes care of lower level message transactions.
Today, VoIP is more than just a tool that enables service providers to
reduce capex and opex. In the present telecom environment, with
networks increasingly being seen as commodities, service providers are
looking to value-added services to provide them with a distinct edge
over their competitors. VoIP has emerged as a potent medium for
providing high value, churn-reducing, differentiated services. In fact,
according to industry analyst Juniper Research, the VoIP industry is
poised to become a $47 billion value-added services market for
broadband service providers by 2009.

Moreover, Probe Research claims that the $63 million VoIP application
server market will grow to around $650 million in 2008.

The applications listed below demonstrate the maximum growth

potential.

Push-To-Talk (PTT)
Push-To-Talk is being actively promoted by leading service providers like
Nextel, Verizon, Orange, Sprint and Alltel. PTT is expected to increase
service provider ARPU by as much as 15 percent. Customer churn will
also decrease due to the affinity nature of group-based calling. Analyst
reports predict more than 300 million PTT subscribers by 2008.

Instant Messaging
The last few years have witnessed tremendous growth in the popularity
of Instant Messaging in both corporate and consumer segments. The
expenditure on messaging applications is expected to double in the
next two to three years.

Multimedia Conferencing
SIP is gaining steady momentum in the multimedia conferencing
domain. This segment had hitherto been characterized by equipment
vendors relying heavily on H.323. With a CAGR of more than 50 percent,
SIP-based multimedia conferencing revenue of service providers is
witnessing a prolific growth rate.

i n fo. f l ex t ro n i c s s o ft wa re . co m
 White Paper

What is B2BUA an d
why is B2BUA important

2. What is B2BUA and why is B2BUA important?

SIP is an application layer protocol that can establish, modify and
terminate multimedia sessions. SIP enables peer-to-peer
communications by enabling the endpoints (hereinafter referred to as
User Agents or simply UAs) to communicate directly. Various network
entities, such as the redirect server, proxies etc help the UAs to
determine the location details of the other end points. Once the
peer-to-peer communication is established, further communication –
either to modify or terminate the session – typically happens between
the peers directly.
While this serves basic communications needs, for call-stateful services
the intermediate network entity needs to have control of the session
between the users involved.
The challenge for infrastructure providers is to provide application
developers with a framework that exposes a comprehensive set of APIs
to help them develop and deploy innovative applications. The problem
becomes more pressing when the typical carrier-grade requirements of
scalability, high-availability and overload protection also need to be
addressed as a part of the offering.
This white paper underscores why FSS' OSA Application Server has
proved to be a panacea for service providers and how it provides a
robust platform for application developers to develop innovative and
powerful applications on.

Call-stateful services include services like Call Queuing, Click-to-dial,

Automatic Call back etc. These services require the intermediate
network entity to have the capability to terminate the call; to terminate
one of the parties involved in the call and re-direct the other party to
the music server; mute one of the parties and feed the relevant
announcements to the other party; or to have the capability to INVITE
two parties and connect them.

For example, in case of the Call Queuing application, the calling party
shall initially be connected to the announcement server – "You are in
queue". Once the operator becomes free, the calling party is connected
to the operator (the connection with the announcement server is
terminated). Similarly in case of the Automatic Call Back feature, the
capability to monitor a given party (using subscribe/notify) and
initiate/invite two parties and connect them is required.

SIP addresses this need by means of B2BUA. SIP defines B2BUA as

follows: "A back-to-back user agent (B2BUA) is a logical entity that
receives a request and processes it as a User Agent Server (UAS). In order
to determine how the request should be answered, it acts as a User
Agent Cient (UAC) and generates requests. Unlike a proxy server, it
maintains dialog state and must participate in all requests sent on the
dialogs it has established. Since it is a concatenation of a UAC and UAS,
no explicit definitions are needed for its behavior." Thus a B2BUA can be
viewed as being functionally similar to a proxy that maintains dialog
state.

The services possible with B2BUA are endless - Call-Queue, Call Pickup,
Click-to-dial, Calling card, Conferencing, Hot Line, Hunt Group, the ability
to delete/reject media streams to control bandwidth in a network,
single-line extension etc.

w w w. f l ex t ro n i c s s o ftware . co m
 White Paper

What is OSA

3. What is OSA?

The OSA specifications define an architecture that enables service The following table has the various SCFs and their mapping protocols:
application developers to make use of network functionality (described
below) through an open standardized interface, which is the OSA Service Capability Feature Network Protocol
Application Programming Interface (API). The network functionality is MultiParty SCF (MPCC SCF) SIP
described in terms of Service Capability Features (SCFs). The OSA
User Interaction SCF (UI SCF) CAP
standard allows easy and faster application development by exposing
Mobility MAP
standard APIs over various SCFs.
Terminal Capabilities Not Applicable
The OSA deployment architecture is depicted in Figure 3-1. Data Session Control CAP/MAP
Account Management Not Applicable
Charging Not Applicable
Policy Management SCF Not Applicable
Presence and Availability Management Not Applicable

The MMCC SCF in an SCS enables an application to establish multiparty

calls where several legs can simultaneously be connected. The MMCC
SCF allows an application to create a leg and to route it. In SIP, to
establish a session it requires at least two SIP endpoints (UAs). The FSS
OSA Application Server provides APIs as defined by the MMCC SCF. This
gives the application the flexibility to create calllegs, move call-legs,
terminate call-legs and manipulate them by either connecting to the
media server or by re-connecting them to originial associated call-leg.
Figure 3-1 : OSA architecture
The application is provided with the capability to monitor media
streams (SDP level) and monitor load towards a given destination
The Parlay/OSA Gateway consists of several Service Capability Servers
gateway.
(SCSs). SCSs are functional entities that provide Parlay/OSA interfaces
towards applications.
The OSA Application Server also provides an enhanced API set for the
application developer
Each SCS is seen by applications as one or more SCFs. SCFs are
. to have finer access to SIP protocol messages
abstractions of the functionality offered by the network, accessible via
. to send and receive proprietary as well as standard SIP messages
the OSA API. Sometimes they are also called services.
(in-dialog as well as out-of-dialog) for presence based applications,
chat applications etc.
The Parlay/OSA SCFs are specified in terms of interface classes and their
. to connect two terminating call-legs (for applications like callpickup
methods; for example, Multimedia Call Control SCF (MMCC SCF),
etc)
UserInteraction SCF (UI SCF), Mobility SCF etc.
. to move call-legs (for applications like call-waiting etc)

Framework - One of the OSA SCSs is called the OSA Framework and
there is always one present per network. This entity provides APIs for the
3.1 Why OSA?
applications to authenticate themselves and to discover the service
Today, as service providers are looking to bundle multiple applications,
capabilities present in the network. It performs the following functions:
they require an Open Service Creation platform to facilitate the
.? Controls access to the network
development and introduction of new services. Legacy Application
.? Integrity management
Servers are mostly based on proprietary architectures, closely tied with
.? Discovery of network functionality
one application or the other. This is why several Tier I vendors have
joined hands and introduced the open OSA standard. FSS believes that
Client Applications - These are actual applications, which make use of
the OSA standard will dominate the Application Server domain in the
services provided by the OSA Framework and various SCSs. They interact
near future - which is borne out by the fact that OSA has already been
with the framework to authenticate and discover the SCS (SCF). They
adopted by 3GPP as a part of the next-generation mobile network
make use of the services provided by the SCS (SCF) to realize the actual
evolution. FSS chose to develop its OSA-compliant Application Server
applications/network services.
Framework since OSA APIs are generic, simple to use and help
application developers to quickly develop innovative applications.
7

i n fo. f l ex t ro n i c s s o ft wa re . co m
 White Paper

Where does the OSA

Application Server fit i n

4. Where does the OSA Application Server fit in?

Figure 4-1 shows a typical SIP Network scenario. As shown in the figure,
the SIP network consists of User Agents (IP Phones); proxy/redirect
servers providing the basic routing functionality; gateways to provide
interconnectivity to other networks; and application servers providing
various services like Call Queuing, Conferencing etc.
Application servers provide specific application(s) and calls from the UAs
are routed to application servers whenever a service is invoked. Basic
functionalities like routing (lookup), forking, authentication etc are
handled by the proxy. This distributed archictecture also helps in
load-balancing across an application server farm.
. SUBSCRIBE/NOTIFY is the mechanism defined by SIP to know the
status of buddies. In the event that an endpoint does not support the
standard-based mechanism, the B2BUA can SUBSCRIBE to the
presence server on behalf of the endpoint and inform the endpoint of
the status of the buddy (through out-ofband means).
As mentioned above, the B2BUA (application server) interacts with the
media server for user interaction and feeding music/announcements.
The application server is capable of instructing the media server which
announcement to feed, how long to feed it etc. With the power of VXML
also incorporated, the services possible with the B2BUA and Media
Servers are limited only by the application developer's imagination.

The FSS OSA Application Server Framework has all the capabilities to
implement all the services and help achieving quick-to-market solution.

Figure 4-1: Typical SIP Network

Calls are routed to application servers only when a service is invoked.

This helps in reducing the load on application server farm and proxy
takes care of routing in case of peer-to-peer communication.

Application servers typically interact with media servers for user

interaction, digit collection and feeding of announcements/music.

The B2BUA is the network element defined by SIP for application server
logic. Apart from providing various services like Click-to-dial, call pick-up
etc, the B2BUA also plays a significant role in providing services on
behalf of other endpoints. These include:

. REFER is the mechanism defined by SIP for call transfer. Assuming only
one of the endpoints (say User A) supports the REFER method, the
B2BUA can act on receiving REFER and establish a call between User B
and User C.

w w w. f l ex t ro n i c s s o ftware . co m
 White Paper

Why the OSA Application

Server is a carrier grade solution

5. Why the OSA Application Server is a
carrier grade solution
Application Servers are considered to be carrier-grade if
- they are the main entities enabling the provision of a wide spectrum of
services
- they address issues of scalability, high-availability, configurability and
overload protection.
As the FSS OSA Application Server addresses all these issues, it can be
considered a truly carrier-grade offering.
5.1 Grow as demand grows
5.2 Round the clock availability
Another issue that is important for service providers is round the clock
availability (leading to less outage).
SIP inherently supports reliability by way of re-transmissions. Being a
transaction-based protocol, every request is re-transmitted till a
response is received. Even if a transaction stateful entity goes down
while a transaction is in progress, reliability is not compromised. This
issue of high availability gains more prominence when discussed in the
context of a call-stateful entity like an application server. The call state
across transactions needs to be maintained, which is crucial for the very
functioning of service logic.

One of the main concerns for service providers is to be able to increase
capacity as demand increases, with fewer overheads. FSS recognizes this
need and consequently, scalability is an important aspect of its entire
product offering.
The following diagram depicts how the OSA Application Server achieves
scalability:
The FSS' OSA Application Server addresses high-availability by providing
appropriate hooks to application developers to construct the stable
critical data and re-construct the full call state based on this critical data.
This coupled with the HA offering of the proxy farm, makes it an ideal
platform for real-time network deployments.

Figure 5-1: Scalability of OSA Application Server

As shown above, it is possible to have separate application servers for

different kinds of services. Whenever a new service is to be added, a new
node can be added. Alternatively, it is possible to introduce the new
service as part of the existing application server node itself.
Figure 5-2: High availability of OSA Application Server
Similarly, when service-handling capacity needs to be enhanced, a new
application server node can be introduced. The routing logic in the proxy
can be re-configured to include the new application server node for load
distribution.

i n fo. f l ex t ro n i c s s o ft wa re . co m
 White Paper

5.3 Overload protection control

Any carrier-grade solution should be able to detect and protect itself

against overload. The OSA Application Server has an in-built load
monitoring capability and can automatically reject new calls when
system capacity is reached. Additionally, it is also possible to monitor
the load towards a given destination gateway.

5.4 Configurability

The OSA Application Server can be easily be configured either using

XML-based configuration file or through a database.

5.5 Distributed versus monolithic architecture

The OSA Application Server supports both CORBA and native C++
interfaces. CORBA offers good scalability and at the same time, has a
penalty of performance. Native C++ interfaces overcome the
performance deficiency; however limit the usage to a monolithic
architecture. Depending on the performance and deployments
requirements, application developers now have a choice to choose
between CORBA and Native-C++ interfaces.

10

w w w. f l ex t ro n i c s s o ftware . co m
 White Paper

Sali ent features

6. Salient features

Some of the salient features of the OSA Application Server include

. OSA compliant APIs
. SA++ APIs for finer application control
. High availability support
. lexibity to configure trigger detection points of application interest
. SIP interface towards media server
. SDP offer answer model support
. RPR support

11

i n fo. f l ex t ro n i c s s o ft wa re . co m
 White Paper
Making advanced
applications a reality
7. Making advanced applications a reality
The following are some of the applications made possible with the FSS
OSA Application Server:
Call Queuing: When an operator access number is dialed, the call is
routed to one of the available operators. When all the operators are
busy, the call is queued and the "You are in queue" announcement is fed.
When one of the operators becomes free, the first call in the queue is
picked up and connected to the operator. Variants of this service include
limiting the duration for which a given subscriber is in a queue, or
feeding an announcement such as "All lines are busy, please try
again".
The operator's status can be monitored either by routing all calls to the
operator through the Application Server or by Subscribing to the
operator's status. The OSA Application Server supports both these
approaches.
Call Pick-up: This could be of two types:
Group Pickup: In this type of pick-up, the subscribers in a given group
will be able to pick up a ringing call made between two other parties in
the group. The call pickup could be based on various algorithms like
'most recent ringing call', 'longest ringing call' etc.
Directed Pickup: In this type of pick-up, the subscriber will be able to
specify whose ringing call shall be picked-up by dialing the called party
number.
Click-To-Dial: In this service, User A, who is browsing through a corporate
website, requests that a call be established between himself and a sales
person. The Application Server initiaties two calls and connects them
through.
Automatic Call Back: User A calls User B, who returns a 'busy' response.
The calling user invokes this service by dialing a specific service code to
request the Application Server to establish a call between User A and
User B whenever User B becomes free.
Alternatively, User A can request the Application Server to initiate this
service by sending an Instant Message to the Application Server.
Call Hunting: When a call is to be delivered a set of locations is tried in
either sequential or progressive order, till the call succeeds. If all the
locations are tried and the call still fails, the call is re-directed to an
announcement server.
Call Completion of a busy subscriber: When a call cannot be
completed due to the called subscriber being busy, the calling user is
given a list of options based on which the call could be connected to a
voice mail server; the busy subscriber could be sent an Instant Message
about the incoming call; the call could be connected to an operator etc.
When an instant message is sent to the busy subscriber, if the
subscriber wishes to honour the new call, the response could be
conveyed in another instant message to the application server. Based on
this response, the call could be routed (re-connected) to the called
party.
Call Waiting: User B is busy in a call with User A. Now, User C tries to
reach User B. User B is informed of the new call and switches between
both the calls (the original call and the new call).
Chat Server: A chat-room is created and messages are exchanged with
a centralized chat server, which handles distribution to all or some of
the participants, based on policy decisions.
Conference Server: Subscribers join a conference using the Application
Server, which facilitates media mixing capabilities with the help of an
external media server. The Application Server can easily implement
various policy capabilities, like who should be allowed to transmit
media, receive media etc.
Bandwidth Monitoring: The Application Server can monitor the
available bandwidth in the network by examining the SDP streams.
Whenever the bandwidth threshold is reached, the server can either
reject the existing calls or delete streams (for e.g. video streams could
be deleted) of certain applications to create more bandwidth.
Prepaid/Calling Card: The Application Server can monitor the duration
of the call and reduce a certain amount from the subscriber's account.
Alternatively, it can inform the subscriber if the account is due to expire
during the course of the call.
12
w w w. f l ex t ro n i c s s o ftware . co m
 White Paper

Simple call-flow for

call queue application

8. Simple call-flow for call queue application 8.3 Connecting a queued subscriber to a free
operator
This section analyzes the call-flow for a Call Queue application and
outlines how the FSS' OSA Application Server makes it easy for The call flow would be as follows:
application developers to build such applications.

In the Call Queue service, when an operator access number is dialed, the
call is routed to one of the available operators. When all the operators
are busy, the call is routed to an announcment server. Whenever any
operator becomes free, the caller is re-connected to that operator.

8.1 Routing to one of the free operators

The call-flow for this would be as follows:

Figure 8-2: Call Queue - Disconnecting annoucement and

routing to available operator

Figure 8-1: Call Queue - Routing to a free operator
1. The application invokes the createNotification () API on the
framework to register for a call origination event.
2. On receiving the INVITE message, the OSA Application Server calls the
reportNotification () API on to the application.
3. Application invokes the createAndRouteCallLegReq () API to route the
call to one of the free operators. The destination address is provided
as an input parameter to this API.
As can be seen from the call-flow, invocation of one API results in
connection to another user (the operator in this case). The associated SIP
signaling (forwarding the INVITE request, associated responses etc) is
encapsulated within this API.
8.2 Connecting to Annoucement Server,
when free operator is not available
When no free operator is available, the call is routed to an
Announcement Server. The call-flow is similar to above call-flow, except
that the destination address is the announcement server. The type of
announcement and duration of announcement etc can be specified as a
part of the Request-URI.
Again, invocation of one API results in connection to the announcement
server. The associated SIP signaling (forwarding the INVITE request,
associated responses etc) is encapsulated as a part of this API.
1. Once a free operator is available, the calling user is put on hold. The
application invokes detachMediaReq () on call-leg A.
2. The OSA Application Server framework does the associated SIP
signaling (that of sending re-INVITE with muted SDP and responding
to 200 OK to re-INVITE with ACK) and informs the application as
detachMediaRes ().
3. Now the call-leg towards media server is released. The application
invokes release () on call-leg.
4. Once the call-leg is released, callLegEnded () callback is given to the
application.
5. Now the application decides to connect User A and the operator. It
invokes attachMediaReq () to make User A one of the active parties in
the connected pair.
6. To establish a call-leg towards the operator, the application invokes
createAndRouteCallLegReq (). This API performs all the associated SIP
signaling (that of sending INVITE with no SDP to operator, sending a
re-INVITE to User A with the SDP offer received in 200 OK etc).
As can be seen from the call-flows, various SIP signaling actions like
muting a call-leg, releasing a call-leg and connectiong two call-legs etc
are encapsulated in easy-to-use intuitive APIs. These APIs keep the
application totally transparent to the SIP signaling.

13

i n fo. f l ex t ro n i c s s o ft wa re . co m
 White Paper

Conclusion

9. Conclusion

In today's competitive telecom business scenario, the enhanced services

segment is proving to be the most dynamic. In the absence of any single
and sustainedly popular application, application developers and service
providers need to constantly introduce new services, identify the most
acceptable service and scale up services at the right time. Given the
unpredictable nature of application revenue, service providers have to
invest in an open service creation architecture over which they can
provide multiple applications at minimal time and cost, thereby
increasing their ROI.

The SIP-based OSA Application Server from FSS has proved to be the
panacea for service providers. It enables Next Generation applications,
provides re-usable components and facilitates the easy addition of new
applications through its 'Open' APIs. The OSA Application Server has
proven to be effective in reducing the time and cost incurred in
providing new applications.

14

w w w. f l ex t ro n i c s s o ftware . co m
 White Paper

Flextronics Software Systems (formerly Hughes Software

Systems-HSS ) is a global end-to-end communications
solutions provider with over 250 customers worldwide, in
the telecom infrastructure and handsets, c ommunication
service providers, systems integrators and independent
software vendors space. It is a part of Flextronics, which
has engineering, manufacturing and logistics operations
in 32 countries spread over five continents. Flextronics
Software Systems has development centers across India
and Germany and associate companies in the Ukraine
and South Africa. It also has sales offices in more than 10
locations worldwide.

United States United Kingdom

1-866- 477-0247 +44-208-6223859
(301)-212-7988

Germany Japan
© 2005 Flextronics Software Systems

+49-160-972-18125 +81-90-9370-9579
+49-911-2527-414 +81-33-5160091

India
+91-124-2455151

w w w. f l ex t ro n i c s s o ft wa re . co m