|
|
This chapter describes the native MM7 communication service in detail.
The native MM7 communication service implements the 3GPP MM7 standard. For more information, see “Appendix A: Standards and Specifications” in Concepts and Architectural Overview, another document in this set.
Using the native MM7 communication service, an application can:
Requests can flow in two directions using the native MM7 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).
There are two types of status reports that can be returned to the application from the network via Gatekeeper. Both are returned asynchronously, using callback information provided when the notification is set up using OAM. If the network sends a report but no notification has been set up, Gatekeeper sends the network an error code indicating permanent failure.
Delivery reports are acknowledgements that the network node has in someway handled the message from the application that was submitted by means of Gatekeeper. The report indicates the status of the message: for example, Forwarded, Expired, or Rejected. There is one delivery report per destination address. If a connection error occurs within Gatekeeper or between Gatekeeper and the application, an error code is returned to the network, which re-sends the message.
Read-reply reports contain the final delivery status of the multimedia message; that is, whether the message has actually been delivered by the network to the mobile terminal. It also includes the status of the message at that terminal: for example, Read or Deleted without being read. Because a recipient can request that read-reply reports not be generated, lack of a read-reply report does not necessarily mean that the message has not been rendered on the recipient’s terminal. There is one read-reply report per destination address. If a connection error occurs within Gatekeeper or between Gatekeeper and the application, an error code is returned to the network, which re-sends the message
| Note: | The Native MM7 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, Gatekeeper does not split the multimedia message. |
In order for an application to receive multimedia messages from the network, it must register its interest in these messages by setting up a subscription using Gatekeeper OAM. A subscription, or notification, is defined by a destination address. For the message to be accepted by Oracle Communications Services Gatekeeper, the destination address must match the subscription. Each registered subscription must be unique, and subscription attempts with overlapping criteria are rejected. If a message with several destination addresses arrives, Gatekeeper will iterate through the list until it reaches a match or the list is exhausted.
| Note: | The Native MM7 communication service does 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, Gatekeeper does not concatenate multimedia message segments into one single multimedia message before delivering it to an application. Gatekeeper regards these as independent multimedia messages. |
off the shelf, the native MM7 communication service supports the following network protocol:
Oracle Communications Services 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 Oracle Communications Services Gatekeeper supports.
Communication services share many common features, covered in “Introducing Communication Services” in 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 native MM7 communication service, including:
The native MM7 communication service writes CDRs in the following conditions:
Native MM7 uses the standard EDR mechanism, documented in Table 15-1. For more information, see Events, Alarms, and Charging.
Table 15-2 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 Gatekeeper for the native 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 native MM7 communication service supports the tel: and mailto: address schemes, and supports short codes.
|