Osa Application Server

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: [email protected] Visit us at: http://www.flextronicssoftware.com

2

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 5.2 5.3 5.4 5.5

Grow as demand grows .....................................................................................................................................................................................................................................................8 Round the clock availability .............................................................................................................................................................................................................................................8 Overload protection control ............................................................................................................................................................................................................................................9 Configurability ......................................................................................................................................................................................................................................................................9 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

3

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

White Paper

Introduction

1. Introduction The Voice over Internet Protocol (VoIP) space has witnessed high velocity growth in the past year - a trend that is likely to continue as the quality and reliability of VoIP technology improves and more companies integrate the technology into their infrastructure. Experts have reported rapid growth in all areas of VoIP technology including adoption, investment and revenue. In fact, Frost & Sullivan predicts that VoIP will account for almost 75 percent of global voice services by 2007. 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.

5

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

As application developers invest in building such value-added services, they need a robust software infrastructure for lower layers. Session Initiation Protocol (SIP), which has been adopted as the standard by bodies like 3GPP, is thus becoming the ubiquitous network protocol and is poised to gradually replace the current SS7 based platform for service creation. Flextronics Software Systems' (FSS) OSA-compliant SIP Application Server with B2BUA functionality enables application developers to concentrate on what they do best - developing applications - while it takes care of lower level message transactions.

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.

6

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 application developers to make use of network functionality (described below) through an open standardized interface, which is the OSA Application Programming Interface (API). The network functionality is described in terms of Service Capability Features (SCFs). The OSA standard allows easy and faster application development by exposing standard APIs over various SCFs. The OSA deployment architecture is depicted in Figure 3-1.

The following table has the various SCFs and their mapping protocols: Service Capability

Feature Network Protocol

MultiParty SCF (MPCC SCF)

SIP

User Interaction SCF (UI SCF)

CAP

Mobility

MAP

Terminal Capabilities

Not Applicable

Data Session Control

CAP/MAP

Account Management

Not Applicable

Charging

Not Applicable

Policy Management SCF

Not Applicable

Presence and Availability Management Not Applicable

Figure 3-1 : OSA architecture The Parlay/OSA Gateway consists of several Service Capability Servers (SCSs). SCSs are functional entities that provide Parlay/OSA interfaces towards applications. Each SCS is seen by applications as one or more SCFs. SCFs are abstractions of the functionality offered by the network, accessible via the OSA API. Sometimes they are also called services. The Parlay/OSA SCFs are specified in terms of interface classes and their methods; for example, Multimedia Call Control SCF (MMCC SCF), UserInteraction SCF (UI SCF), Mobility SCF 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 applications to authenticate themselves and to discover the service capabilities present in the network. It performs the following functions: .? Controls access to the network .? Integrity management .? Discovery of network functionality Client Applications - These are actual applications, which make use of services provided by the OSA Framework and various SCSs. They interact with the framework to authenticate and discover the SCS (SCF). They make use of the services provided by the SCS (SCF) to realize the actual applications/network services.

7

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

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. The application is provided with the capability to monitor media streams (SDP level) and monitor load towards a given destination gateway. The OSA Application Server also provides an enhanced API set for the application developer . to have finer access to SIP protocol messages . to send and receive proprietary as well as standard SIP messages (in-dialog as well as out-of-dialog) for presence based applications, chat applications etc. . to connect two terminating call-legs (for applications like callpickup etc) . to move call-legs (for applications like call-waiting etc)

3.1 Why OSA? Today, as service providers are looking to bundle multiple applications, they require an Open Service Creation platform to facilitate the development and introduction of new services. Legacy Application Servers are mostly based on proprietary architectures, closely tied with one application or the other. This is why several Tier I vendors have joined hands and introduced the open OSA standard. FSS believes that the OSA standard will dominate the Application Server domain in the near future - which is borne out by the fact that OSA has already been adopted by 3GPP as a part of the next-generation mobile network evolution. FSS chose to develop its OSA-compliant Application Server Framework since OSA APIs are generic, simple to use and help application developers to quickly develop innovative applications.

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.

8

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

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

The following diagram depicts how the OSA Application Server achieves scalability:

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

9

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

Figure 5-2: High availability of OSA Application Server

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.

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.

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.

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 This section analyzes the call-flow for a Call Queue application and outlines how the FSS' OSA Application Server makes it easy for application developers to build such applications.

8.3 Connecting a queued subscriber to a free operator The call flow would be as follows:

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

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

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.

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

United States 1-866- 477-0247 (301)-212-7988

United Kingdom +44-208-6223859

Germany +49-160-972-18125 +49-911-2527-414

Japan +81-90-9370-9579 +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

© 2005 Flextronics Software Systems

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.