# Communication Service Reference

# Native MM7 Communication Service

This chapter describes the native MM7 communication service in detail.

## An Overview of the Native MM7 Communication Service

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:

- Send a multimedia message to one or many destination addresses. The payload in these multimedia messages can be any type that can be specified using MIME, including multipart messages. If a subscription for notifications has been previously set up using Gatekeeper OAM, the request can also specify that a delivery report and/or a read report should be returned later in relation to this message.
- Receive delivery reports on sent multimedia messages that have arrived from the network, if this option has been set up using Gatekeeper OAM.
- Receive read-reply reports on sent multimedia messages that have arrived from the network, if this option has been set up using Gatekeeper OAM.
- Receive multimedia messages from the network, if this option has been set up using Gatekeeper OAM.

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).

### Status Reports

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
- Read-Reply Report

#### Delivery Reports

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 Report

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.

### Network-triggered Multimedia Messages

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.

### Supported Network Protocols

off the shelf, the native MM7 communication service supports the following network protocol:

- MM7

#### MM7

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.

## Configuration Specifics for the Native MM7 Communication Service

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:

- Charging Data Records
- Event Data Records
- Statistics
- Supported Address Schemes

### Charging Data Records

#### Generation of CDRs

The native MM7 communication service writes CDRs in the following conditions:

- After an MMS has been successfully sent from the application to the network
- After an MMS has been successfully sent from the network to the application
- After a delivery report has been successfully delivered to the application
- After a read-reply report has been successfully delivered to the application

### Event Data Records

Native MM7 uses the standard EDR mechanism, documented in Table 15-1. For more information, see Events, Alarms, and Charging.

Table 15-1 Event types emitted in native MM7 communication service
EdrId | Meaning
--- | ---
401000 | An application-initiated message has entered the plugin.
401001 | An application-initiated message has exited the plugin.
401002 | A network-triggered message sent via v.1.0 has entered the plugin.
401003 | A network-triggered message has exited the plugin. It is formatted according to v. 1.2.
401004 | A delivery report using v. 1.0 has entered the plugin.
401005 | A delivery report has exited the plugin. It is formatted according to v 1.2
401006 | A read-reply report using v. 1.0 has entered the plugin.
401007 | A read-reply report has exited the plugin. It is formatted according to v. 1.2

### Statistics

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.

Table 15-2 Transaction types for Parlay X 2.1 Multimedia Messaging/MM7 communication service
Method | Transaction type
--- | ---
submit | TRANSACTION_TYPE_MESSAGING_MMS_SEND
deliver | TRANSACTION_TYPE_MESSAGING_MMS_RECEIVE

### Supported Address Schemes

The native MM7 communication service supports the`tel:` and `mailto:` address schemes, and supports short codes.