This chapter describes the Parlay X 2.1 Multimedia Messaging communication service in detail:
The SOAP Service Facade Multimedia Messaging communication service implements the Parlay X 2.1 Multimedia Messaging set of interfaces. For the exact version of the standard this communication service supports, seein Concepts and Architectural Overview, another document in this set.
|Note:||The RESTful Service Facade Multimedia Messaging interfaces provide RESTful access to this same functionality. The internal representations are identical, and for the purposes of creating SLAs and reading CDRs, etc., they are the same.|
Using a Multimedia Messaging communication service, an application can:
The polling capability must be set up in advance. It is controlled through the combined use of parameters send in the request and OAM attributes See Table 9-1 for more information:.
Requests can flow in two directions using the Multimedia Messaging communication service: from the application to the network (called application-initiated or mobile terminated) and from the network to the application (called network-triggered” or mobile originated). Both of these scenarios are covered below.
After an application has sent a multimedia message to one or more destination addresses, two different types of response can be returned:
Send receipts are acknowledgements that the network node has received the multimedia message from the application by means of Oracle Communications Services Gatekeeper. Although a single multimedia message may be sent to multiple destination addresses, normally only one send receipt is returned to the application by Oracle Communications Services Gatekeeper. The receipt is returned synchronously in the response message to the
delivery receipts contain the delivery status of the multimedia message, that is, whether the multimedia message has actually been delivered by the network to the mobile terminal. There is one delivery receipt per destination address, with one of three possible states:
Because actual delivery of the multimedia message may take several hours, or even days (if, for example, the mobile terminal is turned off at the time the multimedia message is sent), delivery receipts are returned asynchronously. Applications can either choose to have delivery receipts delivered to them automatically by supplying Oracle Communications Services Gatekeeper with a callback interface or they can chose to poll Oracle Communications Services Gatekeeper.
If the application supplies a callback interface, there are two possible outcomes:
If the application chooses not to supply a callback interface, Oracle Communications Services Gatekeeper stores the delivery receipt in temporary in-memory storage. The application can poll Oracle Communications Services Gatekeeper for these Receipts. Each stored delivery receipt is timestamped and, after a configurable time period, is removed.
|Note:||The Multimedia Messaging communication service does not put any limitation on the size of the payload in a multimedia message. If the network restricts the size of the payload, Oracle Communications Services Gatekeeper does not split the multimedia message.|
Two sorts of traffic destined for an application can arrive at Oracle Communications Services Gatekeeper from the network, including:
For an application to receive multimedia messages from the network, it must register its interest in these multimedia messages by setting up a subscription in Oracle Communications Services Gatekeeper. A subscription, or notification, is defined by a Service Activation Number, the destination address of the multimedia message.
|Note:||The Service Activation Number may possibly be translated by some mechanism, such as short codes, in the telecom network.|
Additional criteria can be tied to the Service Activation Number, such as the start of the first plain/text part in the multimedia message payload or the subject of the multimedia message. For the message to be accepted by Oracle Communications Services Gatekeeper, both the Service Activation Number and any additional criteria must match the subscription. Each registered subscription must be unique, and subscription attempts with overlapping criteria are rejected. The application may choose either to poll Oracle Communications Services Gatekeeper for received multimedia messages (if polling is enabled) or it may include a callback interface when it sets up the original subscription.
If a multimedia message that matches a subscription arrives at Oracle Communications Services Gatekeeper from the network and the original subscription includes a callback interface, there are two possible results:
If a multimedia message that matches a subscription arrives at Oracle Communications Services Gatekeeper and the original subscription does not include a callback interface, but polling is available, the multimedia message is stored in temporary in-memory storage and Oracle Communications Services Gatekeeper acknowledges the reception of the multimedia message to the network. The application can poll Oracle Communications Services Gatekeeper for any such multimedia messages. Each stored multimedia message is timestamped and, after a configurable time period, is removed.
If a multimedia message arrives at Oracle Communications Services Gatekeeper and no matching subscription is found and polling is not otherwise enabled, Oracle Communications Services Gatekeeper does not acknowledge reception to the network. It is the responsibility of the network node to handle any further processing of the multimedia message.
|Note:||Multimedia Messaging communication services do not put any limitations on the size of the payload in a multimedia message. If the network protocol used restricts the size of the payload, Oracle Communications Services Gatekeeper does not concatenate multimedia message segments into one single multimedia message before delivering it to an application. Oracle Communications Services Gatekeeper regards these as independent multimedia messages.|
Off the shelf, the Multimedia Messaging communication service is configured to support the following network protocol:
Oracle Communications Services Gatekeeper connects to an MMSC using MM7. Seein Concepts and Architectural Overview for the exact version of the standard Oracle Communications Services Gatekeeper supports.
A common feature of messaging-capable networks is the use of short codes and message prefixes to help route traffic and to make access to certain features easier for the end user. Instead of having to use the entire address, users can enter shorter sequences when they dial, which are then mapped to the full address in the network. The Parlay X 2.1 Multimedia Messaging to MM7 communication service supports short codes and message prefixes, which allow the same short code to be mapped to multiple addresses, based on what is prepended to the enclosed message.
Communication services share many common features, covered inin Concepts and Architectural Overview, but each one has a few characteristics that are specific only to that service. This section describes those specific features for the Multimedia Messaging communication service, including:
The Multimedia Messaging/MM7 communication service writes CDRs in the following conditions:
Multimedia Messaging using MM7 uses the standard EDR mechanism, documented in Table 9-2. For more information, see Events, Alarms, and Charging.
Table 9-3 outlines the correlation between the methods being invoked from either the application (in application-initiated requests) or the telecom network (in network-initiated requests) and the transaction type collected by the statistics counters in Oracle Communications Services Gatekeeper for the Parlay X 2. Multimedia Messaging/MM7 communication service:
|Note:||Method names for network-initiated requests are specified by the internal Gatekeeper name, which is not necessarily the same as the message from the network.|
The Parlay X 2.1 Multimedia Messaging/MM7 communication service supports the
mailto: address schemes.