|
|
The following chapter describes the Parlay X 2.1 Multimedia Messaging communication service in detail:
The 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, see “Appendix A: Standards and Specifications” in Concepts and Architectural Overview, another document in this set.
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 request parameter settings and OAM attributes See Table 9-1 below for more information:.
Requests can flow in two directions using the Multimedia Message 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.
Once an application has sent a Multimedia Message to one or more destination addresses, two different types of response can be returned:
Send Receipts are merely acknowledgements that the network node has received the Multimedia Message from the application by means of Network Gatekeeper. Although a single Multimedia Message may be sent to multiple destination addresses, normally only one Send Receipt is returned to the application by Network Gatekeeper. The receipt is returned synchronously in the response message to the sendMessage operation.
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 Network Gatekeeper with a call-back interface or they can chose to poll Network Gatekeeper.
If the application supplies a call-back interface, there are two possible outcomes:
If the application chooses not to supply a call-back interface, Network Gatekeeper stores the Delivery Receipt in temporary in-memory storage. The application can poll Network Gatekeeper for these Receipts. Each stored Delivery Receipt is time-stamped 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, Network Gatekeeper does not split the multimedia message. |
Two sorts of traffic destined for an application can arrive at Network Gatekeeper from the network, including:
In order 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 Network 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 Network 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 Network Gatekeeper for received Multimedia Messages (if it polling is enabled) or it may include a call-back interface when it sets up the original subscription.
If a Multimedia Message that matches a subscription arrives at Network Gatekeeper from the network and the original subscription includes a call-back interface, there are two possible results:
If a Multimedia Message that matches a subscription arrives at Network Gatekeeper and the original subscription does not include a call-back interface, but polling is available, the Multimedia Message is stored in temporary in-memory storage and Network Gatekeeper acknowledges the reception of the Multimedia Message to the network. The application can poll Network Gatekeeper for any such Multimedia Messages. Each stored Multimedia Message is time-stamped and, after a configurable time-period, is removed.
If a Multimedia Message arrives at Network Gatekeeper and no matching subscription is found and polling is not otherwise enabled, Network 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, Network Gatekeeper does not concatenate Multimedia Message segments into one single Multimedia Message before delivering it to an application. Network Gatekeeper regards these as independent Multimedia Messages. |
Off-the shelf, the Multimedia Messaging communication service is configured to support the following network protocol:
Network Gatekeeper connects to an MMSC using MM7. See “Appendix A: Standards and Specifications” in Concepts and Architectural Overview for the exact version of the standard Network 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 in the “Introducing Communication Services” chapter of 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.
The table below 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 Network 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 tel: and mailto: address schemes.
|