|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
See:
Description
Interface Summary | |
---|---|
MessageNotification | The message notification interface delivers the notification. |
MessageNotification_RI | |
MessageNotificationHome | |
MessageNotificationManager | The message notification manager manages the notifications of the application. |
MessageNotificationManager_RI | |
MessageNotificationManagerHome | |
MessageNotificationManagerService | |
MessageNotificationService | |
ReceiveMessage | The operations to retrieve messages that have been received. |
ReceiveMessage_RI | |
ReceiveMessageHome | |
ReceiveMessageService | |
SendMessage | The operations to send messages and check status on sent messages. |
SendMessage_RI | |
SendMessageHome | |
SendMessageService |
Multimedia Messaging.
The present document is part 5 of the Stage 3 Parlay X 2 Web Services specification for Open Service Access (OSA).
The OSA specifications define an architecture that enables application developers to make use of network functionality through an open standardized interface, for example, the OSA APIs.
The present document specifies the Multimedia Messaging Web Service. The following are defined here:
* Name spaces.
* Sequence diagrams.
* Data definitions.
* Interface specification plus detailed method descriptions.
* Fault definitions.
* Service Policies.
* WSDL Description of the interfaces.
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
* References are either specific (identified by date of publication and/or edition number or version number) or nonspecific.
* For a specific reference, subsequent revisions do not apply.
* For a non-specific reference, the latest version applies.
Referenced documents which are not found to be publicly available in the expected location might be found at http://docbox.etsi.org/Reference.
[1] W3C Recommendation (2 May 2001): "XML Schema Part 2: Datatypes".
NOTE: Available at http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/. [2] ETSI ES 202 391-1: "Open Service Access (OSA); Parlay X 2 Web Services;
Part 1: Common".
[3] W3C Note (11 December 2000): "SOAP Messages with Attachments".
NOTE: Available at http://www.w3.org/TR/SOAP-attachments. [4] RFC2822: “Internet Message Format” NOTE: Available at htpp://www.ietf.org/rfc/rfc2822.txt
For the purposes of the present document, the terms and definitions given in ES 202 391-1 [2] apply.
Additionally the following definition is needed:
Whitespace: See definition for CFWS as defined in RFC2822 [4].
For the purposes of the present document, the abbreviations defined in ES 202 391-1 [2] and the following apply:
EMS Enhanced Messaging Service
IM Instant Messaging
MMS Multimedia Messaging Service
MMS-C Multimedia Messaging Service -– Centre
OMA Open Mobile Alliance
SMS Short Message Service
WAP Wireless Application Protocol
Currently, in order to programmatically receive and send Multimedia Messages, it is necessary to write applications using specific protocols to access MMS functions provided by network elements (for example, MMS-C). This approach requires application developers to have a high degree of network expertise.
This contribution defines a Multimedia Messaging Web Service that can map to SMS, EMS, MMS, IM, E-mail, etc.
The choice is between defining one set of interfaces per messaging network or a single set common to all networks; for example, we could define sendMMS, sendEMS, sendSMS, etc., or just use sendMessage. Although the more specific the API the easier it is to use, there are advantages to a single set of network-neutral APIs. These advantages include:
* improved service portability;
* lower complexity, by providing support for generic user terminal capabilities only.
For this version of the Parlay X 2 specification, we provide sets of interfaces for two messaging Web Services: Short Messaging (part 4) and Multimedia Messaging (this part), which provides generic messaging features (including SMS).
Multimedia Messaging provides operations (see clause 8.1, SendMessage API) for sending a Multimedia message to the network and a polling mechanism for monitoring the delivery status of a sent Multimedia message. It also provides an asynchronous notification mechanism for delivery status (see clause 8.3, MessageNotification API).
Multimedia Messaging also allows an application to receive Multimedia messages. Both a polling (see clause 8.2, ReceiveMessage API) and an asynchronous notification mechanism (see clause 8.3, MessageNotification API and clause 8.4, MessageNotificationManager API)) are available.
Figure 1 shows an example scenario using sendMessage and getMessageDeliveryStatus to send data to subscribers and to determine if the data has been received by the subscriber. The application invokes a Web Service to retrieve a stock quote (1) and (2) and sends the current quote - sendMessage - using the Parlay X Interface (3) of the Multimedia Messaging Web Service. After invocation, the Multimedia Message Web Service sends the message to an MMS-C using the MM7 interface (4) for onward transmission (5) to the subscriber over the Mobile network.
Later, when the next quote is ready, the application checks to see - getMessageDeliveryStatus - if the previous quote has been successfully delivered to the subscriber. If not, it may for instance perform an action (not shown) to provide a credit for the previous message transmission. This way, the subscriber is only charged for a stock quote if it is delivered on time.
Alternatively this service could have been built using WAP Push features in the network.
Figure 2 shows an example scenario using sendMessage and getMessageDeliveryStatus to send a link to subscribers and to determine if the data has been received by the subscriber. The application invokes a Web Service to generate a stock quote graph (1) and (2) and sends the current quote as a WAP Push link - sendMessage - using the Parlay X Interface (3) of the Multimedia Messaging Web Service. After invocation, the Multimedia Message Web Service sends the message to an SMS-C (4) for onward transmission (5) to the subscriber over the Mobile network. The subscriber can then open the link and access his content.
The SendMessage interface uses the namespace: http://www.csapi.org/wsdl/parlayx/multimedia_messaging/send/v2_34
The ReceiveMessage interface uses the namespace: http://www.csapi.org/wsdl/parlayx/multimedia_messaging/receive/v2_34
The MessageNotification interface uses the namespace: http://www.csapi.org/wsdl/parlayx/multimedia_messaging/notification/v2_34
The MessageNotificationManager interface uses the namespace: http://www.csapi.org/wsdl/parlayx/multimedia_messaging/notification_manager/v2_45
The data types are defined in the namespace: http://www.csapi.org/schema/parlayx/multimedia_messaging/v2_34
The 'xsd' namespace is used in the present document to refer to the XML Schema data types defined in XML Schema [1]. The use of the name 'xsd' is not semantically significant.
With the advent of picture capable phones, the exchange of photos to mobile phones is becoming more common place. This sequence diagram shows an application where a person can send a picture from an online photo album to a mobile phone.
For phones capable of receiving WAP Push messages, link to content can be sent using this example. The suggested MIME type for the attachment, as defined by the OMA, is text/vnd.wap.sl for sending HTTP links or WAP links to a mobile phone. This sequence diagram shows an application sending a link to a mobile phone, and the mobile phone using the link to retrieve the content.
List of delivery status values.
DeliveredToNetwork
Successful delivery to the network enabler responsible for distributing the multimedia message further in the network.
DeliveryUncertain
Delivery status unknown: for example, because it was handed off to another network.
DeliveryImpossible
Unsuccessful delivery; the message could not be delivered before it expired.
MessageWaiting
The message is still queued for delivery. This is a temporary state, pending transition to one of the preceding states.
DeliveredToTerminal
Successful delivery to Terminal.
DeliveryNotificationNotSupported
Unable to provide delivery receipt notification. The notifyMessageDeliveryReceipt operation will provide “DeliveryNotificationNotSupported” to indicate that delivery receipt for the specified address in a sendMessageRequest message is not supported.
List of delivery priority values.
Default
Default message priority
Low
Low message priority
Normal
Normal message priority
High
High message priority
Delivery status information.
address
xsd:anyURI
Address associated with the delivery status. The address field is coded as a URI.
deliveryStatus
DeliveryStatus
Indicates delivery status for the destination address.
Message information.
messageIdentifier
xsd:string
If present, contains a reference to a message stored in the Parlay X gateway. If the message is pure text, this parameter is not present.
messageService
ActivationNumber
xsd:string
Number associated with the invoked Message service, for example, the destination address used by the terminal to send the message.
senderAddress
xsd:anyURI
Indicates message sender address.
subject
xsd:string
If present, indicates the subject of the received message. This parameter will not be used for SMS services.
priority
MessagePriority
The priority of the message: default is Normal.
message
xsd:string
If present, then the messageIdentifier is not present and this parameter contains the whole message. The type of the message is always pure ASCII text in this case. The message will not be stored in the Parlay X gateway.
dateTime
xsd:dateTime
Time when message was received by operator
Message location information.
bodyText
xsd:string
Contains the message body if it is encoded as ASCII text. fileReferences xsd:anyURI [0..unbounded]
This is an array of URI references to all the attachments in the Multimedia message. These are URIs to different files, for example, GIF pictures or pure text files.
The fault code SVC0230 is reserved and shall not be used,
message Id
SVC0283
text
Delivery Receipt Notification not supported
variables
Service policies for this service.
GroupSupport
xsd:boolean
Groups may be included with addresses
NestedGroupSupport
xsd:boolean
Nested groups are supported in group definitions
ChargingSupported
xsd:boolean
Charging supported for send message operation
|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |