Product Description
 |
 |
 |
|
 |
Get Adobe Reader |
Service Descriptions
The following sections describe the service capabilities of WebLogic Network Gatekeeper:
Overview
This chapter describes the service capabilities available to applications through WebLogic Network Gatekeeper. The descriptions are on a functional level. Each service capability is provided through the Extended Web Services API, as well as through the Parlay X Web Services APIs. The amount of service features supported varies among the APIs. For more information, see Web Services APIs and the specific API descriptions:
- API Descriptions - Extended Web Services for WebLogic Network Gatekeeper
- API Descriptions - Parlay X for WebLogic Network Gatekeeper
Thanks to the modular architecture, it is easy to extend the WebLogic Network Gatekeeper's functionality with legacy and operator specific APIs. For more information on the service integration and extensibility, see Service Extensibility.
Messaging
The messaging service capability makes it possible for an application to send, store, and receive SMSes and Multi Media (MMS) messages. In addition, the service capability supports send lists, smart messaging, EMS, and distribution of ring tones and logos. The send list feature allows for send list distribution of messages.
An operator administrator creates mailboxes with INBOX and OUTBOX folders for each subscriber or application.
An application is notified when a sent message has been successfully delivered to a recipient and when the messaging service receives a message in an INBOX related to the application. Old messages are automatically removed from the mailboxes. The cleanup interval and age of messages to be deleted are configurable.
In addition, destination address short codes and message prefixes can be connected to a mailbox.
A destination address short code is a number that is used by the end user instead of the real mailbox address. The same destination address short code can be used for several mailboxes if it is combined with a message prefix. The message prefix is a string entered by the end user as the first part of the message.
For example, a service provider can have a destination address short code that is used to access all the service provider's messaging based applications. For example 12345. The messages are distributed among the service provider's mailboxes through the use of message prefixes. In this case, each application has its own mailbox. Let's say that the service provider has two applications aimed for a radio show, one for greetings and one for requesting songs. The message prefix for to use can be defined as GREET and SONG. These prefixes are translated by the service capability into the actual mailbox addresses, for example 12333 and 12444.
That is, if an end user wants to request a song, he or she enters 12345 as destination address and starts the actual message with SONG.
In addition, if the service provider wants a general mailbox that is not connected to a specific task, it is possible to define a default mailbox using the same destination address short code (12345). When specifying a default mailbox, no message prefix is specified. This means that all messages sent to 12345 that does not start with GREET or SONG is delivered to the default mailbox, for example 12555.
Charging
The charging service capability makes it possible for an application to charge an end user based on the content (content based charging, CBC) of a used service, for example a song request or a music video, rather than based on the amount of time used. Reservation/payment in parts and immediate charging are supported.
In the example shown in Figure 3-2, Example of messaging using short codes, on page 3-3, the end user could be charged one amount for requesting a song, and another amount for sending a greeting.
In immediate charging the amount is withdrawn from the subscriber's account at the same time the service is ordered.
To make sure the subscriber does not have to pay for a service not delivered, reservation/payment in parts can be used. In this case, the charging service reserves the whole or a part of the amount in the subscriber's account. The amount is not withdrawn until it has been verified that the subscriber has received the whole or a defined part of the service paid for. Reservation/payment in parts can also be used by an application before delivering a service to make sure that the amount to be charged is available on the subscriber's account.
The charging service capability also supports adding money to subscriber accounts.
Call
The call service capability provides applications with functions for call routing, call management, and call leg management. More than two call legs can be connected to a call simultaneously.
Two main usage scenarios for call control are identified; application initiated and network triggered calls.
Network triggered calls
Network triggered call is used for applications where call set up is triggered from the network, see Figure 3-3, Example of a network triggered call, on page 3-5.
The call service capability contains functions that makes it possible for an IN/VAS application to provide:
An application can combine call control with user interaction, user location, and user status. Together, these services make it possible to build all types of traditional IN/VAS services.
Application initiated calls
Typical usage for application initiated calls are voice chat applications and different types of click-to-call functionality in web and office applications. Figure 3-4, Example of an application initiated call, on page 3-6 shows an example where a call is set up using a web based address book application.
In addition, a call between two or more persons can be set up through an application interface. During the call it is possible to add and remove participants through the interface. Also, notifications when individual participants answers and hangs up can be presented.
Subscriber profile
The subscriber profile service capability makes it possible for an application to obtain and manage application subscriber profiles. A subscriber profile consists of data related to a subscriber and the subscriber's telephony terminal, see Table 3-1 on page 6. The data marked as read-only in the table can only be updated by the operator.
Table 3-1 Subscriber Profile Data
User interaction
The user interaction service capability makes it possible for an application to interact with call participant(s) during a call or with messaging users during a messaging session. The application communicates with call participant(s) through announcements or messages and with messaging users through text messages.
Call based user interaction
The call participant(s) communicate through speech or tone sending. That is, both speech recognition and DTMF (using the terminal's key set (0-9, *, #)) can be used. Announcements can be purely informative or they can prompt a participant to reply through speech or sending DTMF tones back to the application.
Message based user interaction
With message based user interaction, the application and the end users communicate through text messages (SMSes or USSD messages).
SMS based user interaction provides application initiated SMSes with a transaction ID to connect requesting/prompting SMSes with end user's replies.
USSD messages from an application can be purely informative or they can prompt the end user to reply. USSD messages can also be used by the end user to initiate service sessions with applications. When initiating service sessions or replying to an application generated USSD message, the end user can only use the terminal's key set (0-9, *, #). The application can use any type of character supported by the end user's terminal.
User location
The user location service capability makes it possible for an application to obtain the geographical location parameters of telephony terminals. The service capability supports:
Both single and periodic requests supports multiple destination addresses in one request.
The user location can be specified as a base point (longitude, latitude) or as a descriptive (abstracted) position.
Using longitude and latitude, the location is specified as a base point (longitude, latitude) and a geometrical area in which the telephony terminal is located. The geometrical area is referred to as an uncertainty shape related to the base point. The uncertainty shapes are expressed in either circles or ellipses.
Using an abstracted position describes the user's location in terms of:
Use of abstracted location information requires interaction with a geographic information system.
When supported in the network, extended location information is also provided, such as altitude, terminal type, and time stamps.
Also, the service capability supports provisioning of geographical information for a terminal, such as city or street address, to applications.
Exactly which parameters that are available to the requesting applications is dependant on the underlying network equipment.
Circle and ellipse uncertainty shapes
When requesting a user location, a set of parameters is returned from the network which describes a circle or ellipse uncertainty shape. Which set of parameters is returned depends on the network equipment. The following three uncertainty shapes can be described:
If the network equipment provides applications with more parameters, the calculations of user locations will be more accurate. Figure 3-5, Parameters for calculating circle uncertainty shapes, on page 3-10 and Figure 3-6, Parameters for calculating ellipse uncertainty shapes, on page 3-11 shows that using more parameters narrows the shaded area in which the user location is found.
Terminal altitude
If the terminal's altitude is provided, the actual terminal altitude is somewhere within a span defined by the provided altitude value and two times the altitude uncertainty, see Figure 3-7, Terminal altitude definition, on page 3-12.
A positive altitude value means above sea level, whereas a negative value means below sea level.
User status
The user status service capability makes it possible for an application to obtain the status of fixed, mobile and IP-based telephony terminals. Possible values are:
The service capability supports both single and periodic status request and as well as multiple destination addresses in one request.
