| Oracle® Communications Services Gatekeeper Communication Service Guide Release 5.1 E37526-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Services Gatekeeper Communication Service Guide Release 5.1 E37526-01 |
|
|
PDF · Mobi · ePub |
This chapter describes the 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 communication service supports for the application-facing interfaces and the network protocols, see the appendix on standards and specifications in Oracle Communications Services Gatekeeper Concepts Guide.
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 about the application interface for the Native MM7 communication service, see the discussion of Native Interfaces in Oracle Communications 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 25-1 lists the IDs of the EDRs created by the Native MM7 communication service.
Table 25-1 Event Types 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 25-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 25-3 lists the technical specifications for the communication service.
Table 25-3 Properties for Native MM7
| Property | Description |
|---|---|
|
Managed object in Administration Console |
domain_name > OCSG > server_name > Communication Services > plugin_instance_id |
|
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 "Managing and Configuring the Plug-in Manager" in Oracle Communications 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 "Managing and Configuring the Plug-in Manager" in Oracle Communications 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:
Attribute: HTTPBasicAuthentication. If using HTTP basic authentication also define:
Specify heartbeat behavior. See "Configuring Heartbeats" in Oracle Communications Services Gatekeeper System Administrator's Guide.
Set up the routing rules to the plug-in instance. See "Managing and Configuring the Plug-in Manager" in Oracle Communications 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 "Defining Global Node and Service Provider Group Node SLAs" and "Managing SLAs" in the Oracle Communications Services Gatekeeper Accounts and SLAs Guide.
Provision the service provider accounts and application accounts. For information, see Oracle Communications Services Gatekeeper Accounts and SLAs 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 "Operation: addVASPIDMapping" to register offline notifications. Use the following operations to manage the offline registrations:
Register online notifications. This means that registrations for mobile-originated messages are managed on behalf of an application. Use "Operation: listVASIDMapping" to register online notifications. Use the following operations to manage the online registrations:
This section describes the attributes and operations for configuration and maintenance:
Scope: Cluster
Unit: Not applicable
Format: Boolean
Specifies if HTTP basic authentication shall be used for authentication with the MM7 server.
Set to true if HTTP basic authentication shall be used, otherwise false.
If true, "Attribute: HTTPBasicAuthenticationUsername" and "Attribute: HTTPBasicAuthenticationPassword" must be specified.
Scope: Cluster
Unit: Not applicable
Format: String
The user name to use for HTTP basic authentication towards the MM7 server. This is equivalent to the Application Instance ID.
Scope: Cluster
Unit: Not applicable
Format: String
The password to use for HTTP basic authentication towards the MM7 server.
Scope: Cluster
Unit: Not applicable
Format: String
Specifies the address of the MM7 Relay Server. The address is an HTTP URL.
Scope: Cluster
Unit: Not applicable
Format: String [REL-5-MM7-1-0, REL-5-MM7-1-2]
Specifies the xsd version that should be used for requests towards the MMSC.
Enter one of the following:
REL-5-MM7-1-0 to use an altered version of the REL-5-MM7-1-0.xsd. The altered version allows the use of delivery notifications when the MMC-S requires this version of the xsd. This is a requirement when connecting to, among others, Comverse MMSCs.
REL-5-MM7-1-2 to use REL-5-MM7-1-2.xsd.
Scope: Cluster
Adds the service provider VAS ID and the Services Gatekeeper VAS ID mapping for use with the submit request.
Signature:
addVASIDMapping(spVasID: String, wlngVasID: String)
Scope: Cluster
Adds the service provider VASP ID and the Oracle Communications Services Gatekeeper VASP ID mapping for use with the SubmitReq operation.
Signature:
addVASPIDMapping(spVaspID: String, wlngVaspID: String)
Scope: Cluster
Sets up delivery notification for network-triggered message delivery. Messages matching this configuration result in a callback to the application by the DeliverReq operation.
Signature:
enableReceiveMmsNotification(Address: String, appInstGroupID: String, applicationURI: String)
Scope: Cluster
Sets up status report notification for delivery status and read-reply status for application-initiated messages.
Signature:
enableStatusReporting(appInstGroupID: String, applicationURI: String)
Scope: Cluster
Checks to see if a notification is already set up for this exact address. If no entry is returned, the address can be used to set up a new notification
Signature:
getReceiveMmsNotificationForAddress(Address: String)
Scope: Cluster
Searches existing configurations for Receive Mms notifications for an address pattern, using regular expressions. If there are no matching configurations, null is returned. This can be used to find out which application is registered for notifications for a specific address.
This operation returns at most 1 match. If there are multiple entries, only the first will be returned, although in normal operation overlapping entries should not be possible
Signature:
getReceiveMmsNotificationMatches(Address: String)
Scope: Cluster
Lists all VAS ID mappings
Signature:
listAllVASIDMapping()
Scope: Cluster
Lists all VASP ID mappings
Signature:
listAllVASPIDMapping()
Scope: Cluster
Lists all established delivery notifications
Signature:
listReceiveMmsNotifications()
Scope: Cluster
Lists all established status report notifications
Signature:
listStatusReportingNotifications()
Scope: Cluster
Lists the VAS ID mapping that corresponds to the specified spVasID
Signature:
listVASIDMapping(spVasID: String)
Scope: Cluster
Lists the VASP ID mapping that corresponds to the specified spVaspID
Signature:
listVASPIDMapping(spVaspID: String)
Scope: Cluster
Removes an existing delivery notification
Signature:
removeReceiveMmsNotification(address: String)
Scope: Cluster
Removes an existing status report notification.
Signature:
removeStatusReporting(applicationInstanceGroupID: String)
Scope: Cluster
Removes an established VAS ID mapping.
Signature:
removeVASIDMapping(spVasID: String)
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
