This chapter describes the Oracle Communications Services Gatekeeper Native MM7 communication service in detail.
The Native MM7 communication service exposes the 3GPP MM7 standard interfaces.
From the point of view of an application, the communication service acts as an MMS relay server. From the point of view of the network, it acts as an MMS VAS application.
For the exact version of the standards that the Native MM7 communication service supports for the application-facing interfaces and the network protocols, see Services Gatekeeper Statement of Compliance.
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 Multipurpose Internet Mail Extensions (MIME), including multipart messages. If a subscription for notifications has been previously set up, the request can also specify that a delivery report 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.
Receive read-reply reports on sent multimedia messages that have arrived from the network.
Receive multimedia messages from the network.
Requests can flow in two directions using the Native MM7 communication service: from the application to the network and from the network to the application.
There are two types of status reports that can be returned to the application from the network via Services Gatekeeper. Both are returned asynchronously, using callback information provided when the notification is set up. If the network sends a report but no notification has been set up, Services Gatekeeper sends the network an error code indicating permanent failure.
Delivery reports are acknowledgements that the network node has handled the message from the application that was submitted. 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 Services Gatekeeper or between Services Gatekeeper and the application, an error code is returned to the network, which resends the message.
Read-reply reports contain the final delivery status of the multimedia message. The final delivery status reports 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 Services Gatekeeper or between Services Gatekeeper and the application, an error code is returned to the network, which resends the message.
For an application to receive multimedia messages from the network, it must register its interest in these messages by setting up a subscription. A subscription, or notification, is defined by a destination address. For the message to be accepted by 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, Services Gatekeeper iterates through the list until it reaches a match or until the list is exhausted.
For information on the application interface for the Native MM7 communication service, see the discussion about the Native Interfaces in Services Gatekeeper Application Developer's Guide.
The Native MM7 communication service generates Event Data Records (EDRs), Charging Data Records (CDRs), alarms, and statistics to assist system administrators and developers in monitoring the service
For general information, see Appendix A, "Events, Alarms, and Charging."
Table 27-1 lists the IDs of the EDRs created by the Native MM7 communication service.
Table 27-1 EDRs Generated by Native MM7
| EDR ID | Description |
|---|---|
|
401000 |
An application-initiated message has entered the plug-in. |
|
401001 |
An application-initiated message has exited the plug-in. |
|
401002 |
A network-triggered message sent via v.1.0 has entered the plug-in. |
|
401003 |
A network-triggered message has exited the plug-in. It is formatted according to v. 1.2. |
|
401004 |
A delivery report using v. 1.0 has entered the plug-in. |
|
401005 |
A delivery report has exited the plug-in. It is formatted according to v 1.2 |
|
401006 |
A read-reply report using v. 1.0 has entered the plug-in. |
|
401007 |
A read-reply report has exited the plug-in. It is formatted according to v. 1.2 |
Native MM7 -specific CDRs are generated under the following conditions:
After an MMS message has been successfully sent from the application to the network.
After an MMS message 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.
Table 27-2 maps methods invoked from either the application or the network to the transaction types collected by the Services Gatekeeper statistics counters.
This section describes the properties and workflow for the Native MM7 communication service.
Table 27-3 lists the technical specifications for the communication service.
Table 27-3 Properties for Native MM7
| Property | Description |
|---|---|
|
Managed object in Administration Console |
To access the managed object, select domain_name, then OCSG, then server_name, then Communication Services, and then plugin_instance_id in that order. |
|
MBean |
Domain=com.bea.wlcp.wlng Name=wlng_nt InstanceName=same as the network protocol instance_id assigned when the plug-in instance is created Type=com.bea.wlcp.wlng.plugin.mm7.management.Mm7MBean |
|
Network protocol plug-in service ID |
Plugin_multimedia_messaging_mm7 |
|
Network protocol plug-in instance ID |
The ID is assigned when the plug-in instance is created. See the discussion about configuring and managing the plug-in manager in Services Gatekeeper System Administrator's Guide. |
|
Supported Address Scheme |
tel, mailto, short |
|
Application-facing interfaces |
com.bea.wlcp.wlng.mm7.plugin.MmsPlugin com.bea.wlcp.wlng.mm7.callback.MmsVaspCallback |
|
Service type |
Mm7 |
|
Exposes to the service communication layer a Java representation of: |
3GPP TS 23.140 V5.3.0 (REL-5-MM7-1-2.xsd) |
|
Interfaces with the network nodes using: |
MM7 (REL-5-MM7-1-0 or REL-5-MM7-1-2) |
|
Deployment artifacts |
Plugin_multimedia_messaging_mm7.jar, mm7_service.jar, 1_0_mm7_vasp.war, 1_2_mm7_vasp.war packaged in wlng_nt_multimedia_messaging_mm7.ear mm7.war, mm7_callback_client.jar packaged in wlng_at_multimedia_messaging_mm7.ear |
Following is an outline for configuring the plug-in using the Administration Console or an MBean browser.
Create one or more instances of the plug-in service. See the discussion about configuring and managing the plug-in manager in Services Gatekeeper System Administrator's Guide. Use the plug-in service ID as listed in the "Properties for Native MM7" section.
Using the Administration Console or an MBean browser, select the MBean for the plug-in instance. The MBean display name is the same as the plug-in instance ID assigned when the plug-in instance was created.
Configure the behavior of the plug-in instance with these fields
Mm7RelayServerAddress
HTTPBasicAuthentication. If using HTTP basic authentication also define: these fields
HTTPBasicAuthenticationUsername
HTTPBasicAuthenticationPassword
XSDVersion
Specify heartbeat behavior. See the discussion on configuring heartbeats in Services Gatekeeper System Administrator's Guide.
Set up the routing rules to the plug-in instance. See the discussion about configuring and managing the plug-in manager in Services Gatekeeper System Administrator's Guide. Use the plug-in instance ID and address schemes listed in the "Properties for Native MM7" section.
Provide the administrator of the MM7 server with the URL to which the MM7 server should deliver mobile-originated messages and delivery reports:
For REL-5-MM7-1-0 the default URL is:
http://IP_Address_of_NT_ Server:port/1_0_mm7_vasp/mms_vasp
For REL-5-MM7-1-2 the default URL is:
http://IP_Address_of_NT Server:port/1_2_mm7_vasp/mms_vasp
If required, create and load a node SLA. For details, see the discussion about defining global node and service provider group node SLAs and managing SLAs in Services Gatekeeper Accounts and SLAs Guide
Provision the service provider accounts and application accounts. For information, see Services Gatekeeper Portal Developer's Guide.
Following is an outline for provisioning Native MM7.
Register offline notifications. This means that mobile-originated messages should not result in notifications to an application, but instead be stored in Services Gatekeeper for polling. Use the addVASPIDMapping method to register offline notifications. Use the following operations to manage the offline registrations:
listAllVASIDMapping
addVASPIDMapping
removeReceiveMmsNotification
Register online notifications. This means that registrations for mobile-originated messages are managed on behalf of an application. Use the addVASPIDMapping method to register online notifications. Use the following methods to manage the online registrations:
listAllVASPIDMapping
enableReceiveMmsNotification
removeStatusReporting
For a description of the attributes and operations of the Mm7MBean MBean, see the ”All Classes” section of Services Gatekeeper OAM Java API Reference.