|
|
As the worlds of Internet applications and of telephony-based functionality continue to converge, many application developers have become frustrated by the unfamiliar and often complex telecom interfaces that they need to master to add even simple telephony-based features to their programs. By using Oracle Communications Services Gatekeeper, telecom operators can instead offer developers a secure, easy-to-develop-for single point of contact with their networks, made up of simple SOAP and Restful Web Service interfaces that can easily be accessed from the Internet using a wide range of tools and languages.
The following chapter presents an overview of Oracle Communications Services Gatekeeper’s functionality, and the ways that application developers can use this functionality to simplify their development projects, including:
There are a few basic concepts you need to understand to create applications that can interact with Oracle Communications Services Gatekeeper:
The basic functional unit in Oracle Communications Services Gatekeeper is the communication service. A communication service consists of a service type (Short Messaging, User Location, etc.), an application-facing interface (also called a “north” interface), and a network-facing interface (also called a “south” interface). A request for service enters through one interface, is subjected to internal processing, including evaluation for policy and protocol translation, and is then sent on using the other interface.
| Note: | Because a single application-facing interface may be connected to multiple protocols and hardware types in the underlying telecom network, it’s important to understand that an application is communicating, finally, with a specific communication service, and not just the north interface. So in some cases it is possible that an application request sent to two different operators, with different underlying network structures, might behave in slightly different ways, even though the initial request uses exactly the same north interface. |
In some Oracle Communications Services Gatekeeper communication services, request traffic can travel in two directions - from the application to the underlying network and from the underlying network to the application - and in others traffic flows in one direction only.
In application-initiated traffic, the application sends a request to Oracle Communications Services Gatekeeper, the request is processed, and a response of some kind is returned synchronously. So, for example, an application could use the Third Party Call interface to set up a call. The initial operation, Make Call, is sent to Oracle Communications Services Gatekeeper (which sends it on to the network) and a string that identifies the call is returned to the application synchronously. To query the status of the call, the application makes a new request, Get Call Information, using the call identifier string to identify the specific call, and then receives the requested information back from Oracle Communications Services Gatekeeper synchronously.
In many cases, application-initiated traffic provides all the functionality necessary to accomplish the desired tasks. But there are certain situations in which useful information may not be immediately available for return to the application. For example, the application might send an SMS to a mobile phone that the user has turned off. The network won’t deliver the message until the user turns the phone back on, which might be hours or even days later. The application can poll to find out whether or not the message has been delivered, using Get SMS Delivery Status, which functions much like Get Call Information described above. But given the possibly extended period of time involved, it would be convenient simply to have the network notify the application once delivery to the mobile phone has been accomplished. To do this, two things must happen:
In order to help telecom operators organize their relationships with application providers, Oracle Communications Services Gatekeeper uses a hierarchical system of accounts. Each application is assigned a unique application instance ID which is tied to an Application Account. All the Application Accounts that belong to a single entity are assigned to a Service Provider Account. Application Accounts with similar requirements are put into Application Groups and Service Providers with similar requirements are put into Service Provider Groups. Each Application Group is associated with an Application Group Service Level Agreement (SLA) and each Service Provider Group are associated with Service Provider Group SLAs. These SLAs define and regulate the contractual agreements between the telecom operator and the application service provider, and cover such things as which services the application may access and the maximum bandwidth available for use.
The communication services based on the RESTful Web Services APIs support the following functionality:
The Third Party Call interface allows an application to set up a call, get information on that call, cancel the call request before it is successfully completed, or end a call that has been successfully set up
The Call Notification interface allows an application to set up and remove call notifications (in which the application is informed of a particular state - busy, unreachable, etc. - of the call) or to set up and remove call direction notifications (in which the application is queried for information on handling a call that is in a particular state).
The SMS interface allows an application to send an SMS, a ringtone, or a logo, and to fetch SMSs and delivery status reports for the application that have been received and stored on Oracle Communications Services Gatekeeper. It also allows an application to start and stop a notification.
The MMS interface allows an application to send an MMS and to fetch information on MMSs for the application that have been received and stored on Oracle Communications Services Gatekeeper. It also allows the application to fetch those messages. The application can also get delivery status on sent messages, and start and stop a notification.
The Terminal Location interface allows an application to get a location for an individual terminal or a group of terminals; to get the distance of the terminal from a specific location; and to start and stop notifications, based on geographic location or on a periodic interval.
The Presence interface allows an application to act as either of two different parties to a presence interaction: as a presentity or as a watcher. A presentity agrees to have certain data (called attributes) such as current activity, available communication means, and contact addresses made available to others while a watcher is a consumer of such information. As a watcher, an application can request to subscribe to all or a subset of a presentity’s data, poll for that data, and start and end presence notifications. As a presentity, an application can publish presence data about itself, check to see if any new watchers wish to subscribe to its presence data, authorize those watchers it chooses to authorize, block those it wishes not to have access, and get a list of currently subscribed watchers.
The Payment interface allows an application to charge an amount to an end-user’s account using Diameter, refund amounts to that account, and split charge amounts among multiple end-users. An application can also reserve amounts, reserve additional amounts, charge against the reservation or release the reservation.
The WAP Push interface allows an application to send a WAP Push message and to receive status notifications about that message. I
The Session Manager interface allows an application to establish a session with the Oracle Communications Services Gatekeeper operator. Operators can choose to use a session-based mode or not.
Application testing in a telecom environment is usually conducted in a stepwise manner. For the first step, applications are run against a simulator (Note: the OCSG SDK simulator does not support RESTful interfaces.). Once basic functional issues are sorted through, the application is connected to an instance of the Oracle Communications Services Gatekeeper attached to a network simulator for non-functional testing. Next the application is tested against a test network, to eliminate any network related issues. Finally, the application can be placed into production on a live network. Figure 2-1 shows the complete application test flow, from the developer’s functional tests to deployment in a live network. While simulator-based tests may be performed in-house by an Application Service Provider, the other tests require the cooperation of the target network operator.
|