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 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 carriers, 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,
MakeCall, is sent to Oracle Communications Services Gatekeeper (which sends it on to the network) and a string, the
CallIdentifier, is returned to the application synchronously. To find out the status of the call, the application makes a new request,
GetCallInformation, using the
CallIdentifier 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
GetSmsDeliveryStatus, which functions much like
GetCallInformation 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.
Oracle Communications Services Gatekeeper allows operators to provide client application developers with a choice of interface types, based on the needs of their applications. Oracle Communications Services Gatekeeper provides SOAP-based Web Services interfaces, RESTful interfaces (see RESTful Application Development Guide), and even two native telephony interfaces (MM7 and SMPP).
|Note:||The exact mix of interfaces depends on the specific Oracle Communications Services Gatekeeper installation.|
The SOAP-based Web Services APIs are based on the Parlay X 2.1 and 3.0 standards and also include three additional Extended Web Services ones to cover Binary SMS, Subscriber Profile, and WAP Push functionality, which are not supported by Parlay X. The functionality supported by these communication services includes:
Using this communication service, an application can set up a call between two parties (the caller and the callee), poll for the status of the call, and end the call. In addition, using the 3.0 communication only, an application can set up a call among multiple participants and add, delete, or transfer those participants. The application can also use the Audio Call communication service to play audio messages to one or multiple of the call participants set up using Third Party Call and, using notifications set up with Call Notification PX 3.0, can also collect digits in response to playing the audio message.
Using this communication service, an application can play audio to one or more call participants in an existing call session set up by PX 3.0 Third Party call, find out if the audio is currently being played, and explicitly end playing the audio. It can also collect digits from a participant in response to an audio message, and in conjunction with a notification set up using Call Notification PX 3. 0, can return that information to the application. It can also interrupt an ongoing interaction such as on-hold music.
Using this communication service, an application can set up and end notifications on call events, such as a callee in a third party call attempt is busy. In addition, in some cases the application can then reroute the call to another party. In addition, using the PX 3.0 communication service, an application can interact with PX 3.0 Audio Call to return digits collected from a call participant back to the application and to end calls.
Using this communication service, an application can send SMS text messages, ringtones, or logos to one or multiple addresses, set up and receive notifications for final delivery receipts of those sent items, and arrange to receive SMSes meeting particular criteria from the network.
Using this communication service, an application can send Multimedia Messages to one or multiple addresses, set up and receive notifications for final delivery receipts of those sent items, and arrange to receive MMSes meeting particular criteria from the network or to poll for such messages.
Using this communication service, an application can request the position of one or more terminals or the distance between a given position and a terminal. It can also set up and receive notifications based on geographic location or time intervals.
Using this communication service, an application can be a watcher for presence information or a presentity (an end user who has agreed to have certain data, such as current activity, available communication means, and contact addresses made available to others). So a presentity might say that at this moment he is in the office and prefers to be contacted by SMS at this number. Before the watcher can receive this information, it must subscribe and be approved by the presentity. Once this is done, the watcher can either poll for specific presentity information, or set up status notifications based on a wide range of criteria published by the presentity. The presentity can control the kinds of information, or attributes, that he makes available to watchers.
Using the communication service based on this interface, an application can charge an end user’s account a specific amount, refund an amount, and split costs among multiple end user accounts. An application can also reserve an amount in an account, extend the amount associated with that reservation, make a charge against that reservation, and release the reservation.
Using the communication service based on this interface, an application can send and receive generic binary objects (for example, a vCard) using SMS mechanisms, and set up and receive notifications. This interface is not based on the Parlay X standards, but instead belongs to the Oracle Extended Web Services (EWS) set.
The application-facing interface of this communication service is not based on the Parlay X 2.1 specification. Many elements within it, however, are based on widely distributed standards. Using the communication service based on this interface, an application can send a WAP Push message, send a replacement WAP Push message, or set up status notifications about previously sent messages.
The application-facing interface of this communication service is based on a subset of that in a proposed Parlay X version. Using this communication service, an application can retrieve particular information or an entire profile (subject to internal filtering) for a subscriber from an LDAP server attached to the network.
There are two native telephony APIs supported by Oracle Communications Services Gatekeeper.
The application-facing interface of this communication service is based on the 3GPP MM7 standard. Using the communication service based on this interface, an application can send and receive MMSs and receive status notifications about previously sent messages.
The application-facing interface of this communication service is based on the SMS Forum standard. Using the communication service based on this interface, an application can send and receive SMSs and receive status notifications about previously sent messages.
Application testing in a telecom environment is usually conducted in a stepwise manner. For the first step, applications are run against simulators like the optional Oracle Communications Services Gatekeeper Simulator. The Oracle Communications Services Gatekeeper Simulator emulates both the Oracle Communications Services Gatekeeper and the underlying network, and allows developers to sort out basic functional issues without having to be connected to a network or network simulator. 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 Oracle Communications Services Gatekeeper Simulator-based tests may be performed in-house by an Application Service Provider, the other tests require the cooperation of the target network operator.