| Oracle® Communication and Mobility Server Administrator's Guide 10g Release 3 (10.1.3) Part Number E12656-01 |
|
|
View PDF |
| Oracle® Communication and Mobility Server Administrator's Guide 10g Release 3 (10.1.3) Part Number E12656-01 |
|
|
View PDF |
This chapter describes OCMS support for the Parlay X Multimedia Messaging Web Services interfaces for developing applications. This chapter contains the following sections:
OCMS implements support for a subset of the operations in the SendMessage, ReceiveMessage, and MessageNotificationManager interfaces, as they are defined in ETSI ES 202 391-5 V1.2.1 (2006-12), Open Service Access (OSA), Parlay X Web Services Part 5: Multimedia Messaging (Parlay X 2).
The Multimedia Messaging Web Services consist of the following interfaces:
SendMessage: Provides operations to send messages and check status of sent messages (Table 10-1).
ReceiveMessage: Provides operations to retrieve messages that have been received (Table 10-2).
MessageNotificationManager: Provides an application side notification interface where notifications about multimedia messages are delivered.(Table 10-3).
MessageNotification: Provides notifications about multimedia messages (Table 10-4).
MessagingNotificationListener: This is a thin Java wrapper layer on top of the Parlay X MessagingNotification interface. An Oracle extension provides the user context if available. The client application should implement this interface and register it using the addMessagingNotificationListener() method from MessagingNotificationListenerManager. Once registered with the manager, it will be called if there is incoming notification. The end client can register multiple listeners. All listeners will be called on every incoming notification. The user context in the form of a SIP address is passed in the context parameter. This class is included in the messagingwsnotification-10.1.3.4.war.
Table 10-1 SendMessage Interface
| Operation | Description |
|---|---|
|
sendMessage |
Request to send a Message to a set of destination addresses, returning a requestIdentifier to identify the message. The requestIdentifier can subsequently be used by the application to poll for the message status. |
|
getMessageDeliveryStatus |
This method is not supported in this implementation, and will always throw a ServiceException with code SVC0001. To get the delivery status on a sent message, call the |
Table 10-2 ReceiveMessage Interface
| Operation | Description |
|---|---|
|
getReceivedMessages |
This method is not supported in this implementation. Clients are not allowed to poll for received messages; instead, they must use the |
|
getMessageURIs |
This method is not supported in this implementation – calling this method will always result in a ServiceException with code SVC001. |
|
getMessage |
This method will read the whole message. The data is returned as an attachment in the return message. |
Table 10-3 MessageNotificationManager Interface
| Operation | Description |
|---|---|
|
startMessageNotification |
Start notifications to the application for a given Message Service activation number and criteria. Implemented according to the Parlay X 2.1 specification, section 8.4.1, with the clarifications described in:"Interface: MessageNotificationManager, Operation: startMessageNotification". |
|
stopMessageNotification |
This operations allows an application to end a multimedia message notification. Implemented according to the Parlay X 2.1 specification, section 8.4.2, with the clarifications described in "Interface: MessageNotificationManager, Operation: stopMessageNotification" |
Table 10-4 MessageNotification Interface
| Operation | Description |
|---|---|
|
notifyMessageReception |
This notification is sent when a message is received by the server from the SIP network. The MessageReference's Subject will contain the text message if the content-type is plain-text. |
|
notifyMessageDeliveryReceipt |
This notification is sent if either the message has been delivered or if delivery is impossible. |
This section provides guidelines for using each of the operations in the interfaces.
This method is always invoked on behalf of an actual end user. The end user is identified by a SIP Address-Of-Record (AOR). We determine the AOR by parsing the from part of the message request:
The requestIdentifier returned should not be used to poll for message status using the getMessageDeliveryStatus method because this implementation does not implement the getMessageDeliveryStatus method. Instead, pass in a valid SimpleReference object to the sendMessage method in order to get a notification of the delivery status once it is available for each of the target URIs.
The senderAddress, priority and charging parameters are presently ignored.
Group URLs are not supported.
If the caller of this method includes an attachment in the SOAP context, then that attachment is presumed to contain the body of the message, in which case the subject parameter is ignored; the raw contents of the attachment ( bytes ) are sent to the target URIs. If, however, the caller does not include a SOAP attachment, then it is presumed that the subject parameter consists of the whole message – therefore a SIP message with content type text/plain is sent to the target recipients.
This method is not supported in this implementation, and will always throw a ServiceException with code SVC0001. To get the delivery status on a sent message, call the sendMessage method with a valid SimpleReference pointing to the notification endpoint which will be invoked for each of the target URIs.
This method is not supported in this implementation, and will always throw a ServiceException with code SVC001. Clients are not allowed to poll for received messages; instead, they must use the startMessageNotification method of the MessageNotificationManager interface to register the notification endpoint that will be invoked whenever a new message is available for the endpoint user.
This method is not supported in this implementation – calling this method will always result in a ServiceException with code SVC001.
Implemented according to the Parlay X 2.1 specification, section 8.2.3, with the following clarification:
Whenever this method is called with a messageRefIdentifier that does not exist on the server, a ServiceException with error code SVC002 is thrown.
Implemented according to the Parlay X 2.1 specification, section 8.4.1, with the following clarifications:
The messageServiceActivationNumber translates to the SIP Address-Of-Record of the user for whom message notifications will be delivered.
The criteria parameter is currently ignored.
The correlator parameter in the SimpleReference object used in this method must be globally unique for every instance of an end user on any client. See discussion under stopMessageNotification below.
Implemented according to the Parlay X 2.1 specification, section 8.4.2, with the following clarification:
Since the messageServiceActicationNumber provided in the call to startMessgeNotification is the SIP AOR of the end user, then the correlator passed to stopMessageNotification must be able to be uniquely mapped to a particular end-user instance from a particular client. Therefore, we require that the notification correlator be globally unique for each end user instance on any client, so that we can correctly map the stop notification request to the correct user instance.
