ETSI ES 202 391-5 V1.3.1 (2008-05)
Open Service Access (OSA); Parlay X Web Services; Part 5: Multimedia Messaging (Parlay X 2)
Open Service Access (OSA); Parlay X Web Services; Part 5: Multimedia Messaging (Parlay X 2)
RES/TISPAN-01056-05-OSA
Odprti dostop do storitve (OSA) - Spletne storitve Parlay X - 5. del: Večpredstavnostno sporočanje (Parlay X 2)
General Information
Buy Standard
Standards Content (Sample)
ETSI ES 202 391-5 V1.3.1 (2008-05)
ETSI Standard
Open Service Access (OSA);
Parlay X Web Services;
Part 5: Multimedia Messaging
(Parlay X 2)
�
---------------------- Page: 1 ----------------------
2 ETSI ES 202 391-5 V1.3.1 (2008-05)
Reference
RES/TISPAN-01056-05-OSA
Keywords
API, OSA, service
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2008.
© The Parlay Group 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
---------------------- Page: 2 ----------------------
3 ETSI ES 202 391-5 V1.3.1 (2008-05)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.6
2 References.6
2.1 Normative references.6
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.7
4 Detailed service description .7
5 Namespaces.9
6 Sequence diagrams.9
6.1 Send picture.9
6.2 Send WAP Push message.10
7 XML Schema data type definition .11
7.1 DeliveryStatus enumeration.11
7.2 MessagePriority enumeration.11
7.3 DeliveryInformation structure.12
7.4 MessageReference structure.12
7.5 MessageURI structure.12
8 Web Service interface definition.12
8.1 Interface: SendMessage.12
8.1.1 Operation: sendMessage.12
8.1.1.1 Input message: sendMessageRequest.13
8.1.1.2 Output message: sendMessageResponse.13
8.1.1.3 Referenced faults.13
8.1.2 Operation: getMessageDeliveryStatus.14
8.1.2.1 Input message: getMessageDeliveryStatusRequest .14
8.1.2.2 Output message: getMessageDeliveryStatusResponse .14
8.1.2.3 Referenced faults.14
8.2 Interface: ReceiveMessage.14
8.2.1 Operation: getReceivedMessages.14
8.2.1.1 Input message: getReceivedMessagesRequest.15
8.2.1.2 Output message: getReceivedMessagesResponse.15
8.2.1.3 Referenced faults.15
8.2.2 Operation: getMessageURIs.15
8.2.2.1 Input message: getMessageURIsRequest.15
8.2.2.2 Output message: getMessageURIsResponse.15
8.2.2.3 Referenced faults.15
8.2.3 Operation: getMessage.16
8.2.3.1 Input message: getMessageRequest .16
8.2.3.2 Output message: getMessageResponse.16
8.2.3.3 Referenced faults.16
8.3 Interface: MessageNotification.16
8.3.1 Operation: notifyMessageReception.16
8.3.1.1 Input message: notifyMessageReceptionRequest .16
8.3.1.2 Output message: notifyMessageReceptionResponse.17
8.3.1.3 Referenced faults.17
8.3.2 Operation: notifyMessageDeliveryReceipt.17
8.3.2.1 Input message: notifyMessageDeliveryReceiptRequest .17
8.3.2.2 Output message: notifyMessageDeliveryReceiptResponse .17
8.3.2.3 Referenced faults.17
8.4 Interface: MessageNotificationManager .17
8.4.1 Operation: startMessageNotification.18
ETSI
---------------------- Page: 3 ----------------------
4 ETSI ES 202 391-5 V1.3.1 (2008-05)
8.4.1.1 Input message: startMessageNotificationRequest.18
8.4.1.2 Output message: startMessageNotificationResponse.18
8.4.1.3 Referenced Faults.18
8.4.2 Operation: stopMessageNotification.18
8.4.2.1 Input message: stopMessageNotificationRequest .19
8.4.2.2 Output message: stopMessageNotificationResponse.19
8.4.2.3 Referenced Faults.19
9 Fault definitions.19
9.1 ServiceException.19
9.1.1 Void.19
9.1.2 SVC0283: Delivery Receipt Notification not supported.19
10 Service policies .19
Annex A (normative): WSDL for Multimedia Messaging.20
Annex B (informative): Bibliography.21
History .22
ETSI
---------------------- Page: 4 ----------------------
5 ETSI ES 202 391-5 V1.3.1 (2008-05)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Standard (ES) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
The present document is part 5 of a multi-part deliverable covering Open Service Access (OSA); Parlay X
Web Services, as identified below:
Part 1: "Common";
Part 2: "Third Party Call";
Part 3: "Call Notification";
Part 4: "Short Messaging";
Part 5: "Multimedia Messaging";
Part 6: "Payment";
Part 7: "Account Management";
Part 8: "Terminal Status";
Part 9: "Terminal Location";
Part 10: "Call Handling";
Part 11: "Audio Call";
Part 12: "Multimedia Conference";
Part 13: "Address List Management";
Part 14: "Presence".
The present document has been defined jointly between ETSI, The Parlay Group (http://www.parlay.org) and the 3GPP.
The present document forms part of the Parlay X 2.2 set of specifications.
The present document is equivalent to 3GPP TS 29.199-05 V6.8.0 (Release 6).
ETSI
---------------------- Page: 5 ----------------------
6 ETSI ES 202 391-5 V1.3.1 (2008-05)
1 Scope
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, i.e. 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.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably,
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the
method of access to the referenced document and the full network address, with the same punctuation and use of upper
case and lower case letters.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] W3C Recommendation (2 May 2001): "XML Schema Part 2: Datatypes".
NOTE: Available at: http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.
ETSI
---------------------- Page: 6 ----------------------
7 ETSI ES 202 391-5 V1.3.1 (2008-05)
[2] ETSI ES 202 391-1: "Open Service Access (OSA); Parlay X Web Services; Part 1: Common
(Parlay X 2)".
[3] W3C Note (11 December 2000): "SOAP Messages with Attachments".
NOTE: Available at: http://www.w3.org/TR/SOAP-attachments.
[4] IETF RFC 2822: "Internet Message Format".
NOTE: Available at: http://www.ietf.org/rfc/rfc2822.txt
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 202 391-1 [2] and the following apply:
Whitespace: See definition for CFWS as defined in RFC 2822 [4].
3.2 Abbreviations
For the purposes of the present document, the abbreviations given 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
4 Detailed service description
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 (e.g. 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;
e.g. 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 (the present document), 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.
ETSI
---------------------- Page: 7 ----------------------
8 ETSI ES 202 391-5 V1.3.1 (2008-05)
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.
Multimedia
Stock Quote
Message Web
Stock Quote MMSC -X
Web Service
Service 4
Web Service component
Parlay X I/F
MMS-C
MMSC
MM7 VASP
Interface
1
3
5
…… .
content1 =get StockQuote ()
….
Retrieve
user Profile
Mobile network
….
content
messageId= sendMessage( )
1
….
2
6
status= getMessageDeliveryStatus (messageId)
if status=Message_Waiting
….
fi
User
…
profile
content2 =get StockQuote ()
messageId= sendMessage ( content2 )
Figure 1: Multimedia Messaging Scenario
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.
ETSI
---------------------- Page: 8 ----------------------
9 ETSI ES 202 391-5 V1.3.1 (2008-05)
Figure 2: WAP Push scenario
5 Namespaces
The SendMessage interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/multimedia_messaging/send/v2_5
The ReceiveMessage interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/multimedia_messaging/receive/v2_5
The MessageNotification interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/multimedia_messaging/notification/v2_4
The MessageNotificationManager interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/multimedia_messaging/notification_manager/v2_6
The data types are defined in the namespace:
http://www.csapi.org/schema/parlayx/multimedia_messaging/v2_4
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.
6 Sequence diagrams
6.1 Send picture
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.
ETSI
---------------------- Page: 9 ----------------------
10 ETSI ES 202 391-5 V1.3.1 (2008-05)
: End User : Online Photo : Send MMS
Album Web Service
User logs on
User selects photo to send
User fills in send information
Send multimedia message
Message identifier
Short wait
Get message status
Status
Acknowledgement page
Figure 3
6.2 Send WAP Push message
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.
ETSI
---------------------- Page: 10 ----------------------
11 ETSI ES 202 391-5 V1.3.1 (2008-05)
Service Content
Send MMS Mobile
provider
Web Service Phone
Add
attachments
Send multimedia message
Message identifier
Link sent to phone
Short wait Phone
Get message status processes
message
Status
Access
link
User enjoys
content
Figure 4
7 XML Schema data type definition
7.1 DeliveryStatus enumeration
List of delivery status values.
Enumeration value Description
DeliveredToNetwork Successful delivery to the network enabler responsible for distributing the multimedia
message further in the network.
DeliveryUncertain Delivery status unknown: e.g. 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.
DeliveryNotificationNot Unable to provide delivery receipt notification. The notifyMessageDeliveryReceipt
Supported operation will provide "DeliveryNotificationNotSupported" to indicate that delivery
receipt for the specified address in a sendMessageRequest message is not
supported.
7.2 MessagePriority enumeration
List of delivery priority values.
Enumeration value Description
Default Default message priority
Low Low message priority
Normal Normal message priority
High High message priority
ETSI
---------------------- Page: 11 ----------------------
12 ETSI ES 202 391-5 V1.3.1 (2008-05)
7.3 DeliveryInformation structure
Delivery status information.
Element name Element type Optional Description
address xsd:anyURI No Address associated with the delivery status. The address field
is coded as a URI.
deliveryStatus DeliveryStatus No Indicates delivery status for the destination address.
7.4 MessageReference structure
Message information.
Element name Element type Optional Description
messageIdentifier xsd:string Yes 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 xsd:string No Number associated with the invoked Message service, i.e. the
ActivationNumber destination address used by the terminal to send the message.
senderAddress xsd:anyURI No Indicates message sender address.
subject xsd:string Yes If present, indicates the subject of the received message. This
parameter will not be used for SMS services.
priority MessagePriority No The priority of the message: default is Normal.
message xsd:string Yes 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 Yes Time when message was received by operator
7.5 MessageURI structure
Message location information.
Element name Element type Optional Description
bodyText xsd:string Yes Contains the message body if it is encoded as ASCII text.
fileReferences xsd:anyURI [0.unbounded] Yes This is an array of URI references to all the attachments in
the Multimedia message. These are URIs to different files,
e.g. GIF pictures or pure text files.
8 Web Service interface definition
8.1 Interface: SendMessage
Operations to send messages and check status on sent messages.
8.1.1 Operation: 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, i.e. using
getMessageDeliveryStatus to see if the message has been delivered or not. The content is sent as one or more
attachments as specified in SOAP Messages with Attachments [3].
addresses may include group URIs as defined in the Address List Management specification. If groups are not
supported, a fault (POL0006) will be returned to the application.
ETSI
---------------------- Page: 12 ----------------------
13 ETSI ES 202 391-5 V1.3.1 (2008-05)
Optionally the application can also indicate the sender address (senderAddress), i.e. the string that is displayed on the
user's terminal as the originator of the message, the message priority, the message subject, the charging information
and a receiptRequest. The receiptRequest which is a SimpleReference structure indicates the application endpoint,
interface used for notification of delivery receipt and a correlator that uniquely identifies the sending request. By
invoking this operation with the optional receiptRequest part the application requires to receive the notification of the
status of the message delivery.
If the notification mechanism is not supported by a network a fault (SVC0283) will be returned to the application and
the message will not be sent to the addresses specified. Notification to the application is done by invoking the
notifyMessageDeliveryReceipt operation at the endpoint specified in receiptRequest.
The correlator provided in the receiptRequest must be unique for this Web Service and application at the time the
notification is initiated, otherwise a ServiceException (SVC0005) will be returned to the application.
8.1.1.1 Input message: sendMessageRequest
Part name Part type Optional Description
addresses xsd:anyURI [0.unbounded] No Destination addresses for the Message.
senderAddress xsd:string Yes Message sender address. This parameter is not
rd
allowed for all 3 party providers. Parlay X server
needs to handle this according to a SLA for the
specific application and its use can therefore result in
a PolicyException.
subject xsd:string Yes Message subject. If mapped to SMS this parameter
will be used as the senderAddress, even if a
separate senderAddress is provided.
priority MessagePriority Yes Priority of the message. If not present, the network will
assign
...
Final draft ETSI ES 202 391-5 V1.3.1 (2008-02)
ETSI Standard
Open Service Access (OSA);
Parlay X Web Services;
Part 5: Multimedia Messaging
(Parlay X 2)
�
---------------------- Page: 1 ----------------------
2 Final draft ETSI ES 202 391-5 V1.3.1 (2008-02)
Reference
RES/TISPAN-01056-05-OSA
Keywords
API, OSA, service
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2008.
© The Parlay Group 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
---------------------- Page: 2 ----------------------
3 Final draft ETSI ES 202 391-5 V1.3.1 (2008-02)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.6
2 References.6
2.1 Normative references.6
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.7
4 Detailed service description .7
5 Namespaces.9
6 Sequence diagrams.9
6.1 Send picture.9
6.2 Send WAP Push message.10
7 XML Schema data type definition .11
7.1 DeliveryStatus enumeration.11
7.2 MessagePriority enumeration.11
7.3 DeliveryInformation structure.12
7.4 MessageReference structure.12
7.5 MessageURI structure.12
8 Web Service interface definition.12
8.1 Interface: SendMessage.12
8.1.1 Operation: sendMessage.12
8.1.1.1 Input message: sendMessageRequest.13
8.1.1.2 Output message: sendMessageResponse.13
8.1.1.3 Referenced faults.13
8.1.2 Operation: getMessageDeliveryStatus.14
8.1.2.1 Input message: getMessageDeliveryStatusRequest .14
8.1.2.2 Output message: getMessageDeliveryStatusResponse .14
8.1.2.3 Referenced faults.14
8.2 Interface: ReceiveMessage.14
8.2.1 Operation: getReceivedMessages.14
8.2.1.1 Input message: getReceivedMessagesRequest.15
8.2.1.2 Output message: getReceivedMessagesResponse.15
8.2.1.3 Referenced faults.15
8.2.2 Operation: getMessageURIs.15
8.2.2.1 Input message: getMessageURIsRequest.15
8.2.2.2 Output message: getMessageURIsResponse.15
8.2.2.3 Referenced faults.15
8.2.3 Operation: getMessage.16
8.2.3.1 Input message: getMessageRequest .16
8.2.3.2 Output message: getMessageResponse.16
8.2.3.3 Referenced faults.16
8.3 Interface: MessageNotification.16
8.3.1 Operation: notifyMessageReception.16
8.3.1.1 Input message: notifyMessageReceptionRequest .16
8.3.1.2 Output message: notifyMessageReceptionResponse.17
8.3.1.3 Referenced faults.17
8.3.2 Operation: notifyMessageDeliveryReceipt.17
8.3.2.1 Input message: notifyMessageDeliveryReceiptRequest .17
8.3.2.2 Output message: notifyMessageDeliveryReceiptResponse .17
8.3.2.3 Referenced faults.17
8.4 Interface: MessageNotificationManager .17
8.4.1 Operation: startMessageNotification.18
ETSI
---------------------- Page: 3 ----------------------
4 Final draft ETSI ES 202 391-5 V1.3.1 (2008-02)
8.4.1.1 Input message: startMessageNotificationRequest.18
8.4.1.2 Output message: startMessageNotificationResponse.18
8.4.1.3 Referenced Faults.18
8.4.2 Operation: stopMessageNotification.18
8.4.2.1 Input message: stopMessageNotificationRequest .19
8.4.2.2 Output message: stopMessageNotificationResponse.19
8.4.2.3 Referenced Faults.19
9 Fault definitions.19
9.1 ServiceException.19
9.1.1 Void.19
9.1.2 SVC0283: Delivery Receipt Notification not supported.19
10 Service policies .19
Annex A (normative): WSDL for Multimedia Messaging.20
Annex B (informative): Bibliography.21
History .22
ETSI
---------------------- Page: 4 ----------------------
5 Final draft ETSI ES 202 391-5 V1.3.1 (2008-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Standard (ES) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN), and is now submitted for the ETSI standards
Membership Approval Procedure.
The present document is part 5 of a multi-part deliverable covering Open Service Access (OSA); Parlay X
Web Services, as identified below:
Part 1: "Common";
Part 2: "Third Party Call";
Part 3: "Call Notification";
Part 4: "Short Messaging";
Part 5: "Multimedia Messaging";
Part 6: "Payment";
Part 7: "Account Management";
Part 8: "Terminal Status";
Part 9: "Terminal Location";
Part 10: "Call Handling";
Part 11: "Audio Call";
Part 12: "Multimedia Conference";
Part 13: "Address List Management";
Part 14: "Presence".
The present document has been defined jointly between ETSI, The Parlay Group (http://www.parlay.org) and the 3GPP.
The present document forms part of the Parlay X 2.2 set of specifications.
The present document is equivalent to 3GPP TS 29.199-05 V6.8.0 (Release 6).
ETSI
---------------------- Page: 5 ----------------------
6 Final draft ETSI ES 202 391-5 V1.3.1 (2008-02)
1 Scope
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, i.e. 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.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably,
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the
method of access to the referenced document and the full network address, with the same punctuation and use of upper
case and lower case letters.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] W3C Recommendation (2 May 2001): "XML Schema Part 2: Datatypes".
NOTE: Available at: http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.
ETSI
---------------------- Page: 6 ----------------------
7 Final draft ETSI ES 202 391-5 V1.3.1 (2008-02)
[2] ETSI ES 202 391-1: "Open Service Access (OSA); Parlay X Web Services; Part 1: Common
(Parlay X 2)".
[3] W3C Note (11 December 2000): "SOAP Messages with Attachments".
NOTE: Available at: http://www.w3.org/TR/SOAP-attachments.
[4] IETF RFC 2822: "Internet Message Format".
NOTE: Available at: http://www.ietf.org/rfc/rfc2822.txt
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 202 391-1 [2] and the following apply:
Whitespace: See definition for CFWS as defined in RFC 2822 [4].
3.2 Abbreviations
For the purposes of the present document, the abbreviations given 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
4 Detailed service description
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 (e.g. 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;
e.g. 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 (the present document), 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.
ETSI
---------------------- Page: 7 ----------------------
8 Final draft ETSI ES 202 391-5 V1.3.1 (2008-02)
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.
Multimedia
Stock Quote
Message Web
Stock Quote MMSC -X
Web Service
Service 4
Web Service component
Parlay X I/F
MMS-C
MMSC
MM7 VASP
Interface
1
3
5
…… .
content1 =getStockQuote ()
….
Retrieve
user Profile
Mobile network
….
sendMessage( content )
messageId=
1
….
2
6
status= getMessageDeliveryStatus (messageId)
if status=Message_Waiting
….
fi
User
…
profile
content2 =getStockQuote ()
messageId= sendMessage ( content2 )
Figure 1: Multimedia Messaging Scenario
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.
ETSI
---------------------- Page: 8 ----------------------
9 Final draft ETSI ES 202 391-5 V1.3.1 (2008-02)
Figure 2: WAP Push scenario
5 Namespaces
The SendMessage interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/multimedia_messaging/send/v2_5
The ReceiveMessage interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/multimedia_messaging/receive/v2_5
The MessageNotification interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/multimedia_messaging/notification/v2_4
The MessageNotificationManager interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/multimedia_messaging/notification_manager/v2_6
The data types are defined in the namespace:
http://www.csapi.org/schema/parlayx/multimedia_messaging/v2_4
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.
6 Sequence diagrams
6.1 Send picture
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.
ETSI
---------------------- Page: 9 ----------------------
10 Final draft ETSI ES 202 391-5 V1.3.1 (2008-02)
: End User : Online Photo : Send MMS
Album Web Service
User logs on
User selects photo to send
User fills in send information
Send multimedia message
Message identifier
Short wait
Get message status
Status
Acknowledgement page
Figure 3
6.2 Send WAP Push message
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.
ETSI
---------------------- Page: 10 ----------------------
11 Final draft ETSI ES 202 391-5 V1.3.1 (2008-02)
Service Content
Send MMS
Mobile
provider
Web Service
Phone
Add
attachments
Send multimedia message
Message identifier
Link sent to phone
Short wait Phone
processes
Get message status
message
Status
Access
link
User enjoys
content
Figure 4
7 XML Schema data type definition
7.1 DeliveryStatus enumeration
List of delivery status values.
Enumeration value Description
DeliveredToNetwork Successful delivery to the network enabler responsible for distributing the multimedia
message further in the network.
DeliveryUncertain Delivery status unknown: e.g. 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.
DeliveryNotificationNot Unable to provide delivery receipt notification. The notifyMessageDeliveryReceipt
Supported operation will provide "DeliveryNotificationNotSupported" to indicate that delivery
receipt for the specified address in a sendMessageRequest message is not
supported.
7.2 MessagePriority enumeration
List of delivery priority values.
Enumeration value Description
Default Default message priority
Low Low message priority
Normal Normal message priority
High High message priority
ETSI
---------------------- Page: 11 ----------------------
12 Final draft ETSI ES 202 391-5 V1.3.1 (2008-02)
7.3 DeliveryInformation structure
Delivery status information.
Element name Element type Optional Description
address xsd:anyURI No Address associated with the delivery status. The address field
is coded as a URI.
deliveryStatus DeliveryStatus No Indicates delivery status for the destination address.
7.4 MessageReference structure
Message information.
Element name Element type Optional Description
messageIdentifier xsd:string Yes 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 xsd:string No Number associated with the invoked Message service, i.e. the
ActivationNumber destination address used by the terminal to send the message.
senderAddress xsd:anyURI No Indicates message sender address.
subject xsd:string Yes If present, indicates the subject of the received message. This
parameter will not be used for SMS services.
priority MessagePriority No The priority of the message: default is Normal.
message xsd:string Yes 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 Yes Time when message was received by operator
7.5 MessageURI structure
Message location information.
Element name Element type Optional Description
bodyText xsd:string Yes Contains the message body if it is encoded as ASCII text.
fileReferences xsd:anyURI [0.unbounded] Yes This is an array of URI references to all the attachments in
the Multimedia message. These are URIs to different files,
e.g. GIF pictures or pure text files.
8 Web Service interface definition
8.1 Interface: SendMessage
Operations to send messages and check status on sent messages.
8.1.1 Operation: 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, i.e. using
getMessageDeliveryStatus to see if the message has been delivered or not. The content is sent as one or more
attachments as specified in SOAP Messages with Attachments [3].
addresses may include group URIs as defined in the Address List Management specification. If groups are not
supported, a fault (POL0006) will be returned to the application.
ETSI
---------------------- Page: 12 ----------------------
13 Final draft ETSI ES 202 391-5 V1.3.1 (2008-02)
Optionally the application can also indicate the sender address (senderAddress), i.e. the string that is displayed on the
user's terminal as the originator of the message, the message priority, the message subject, the charging information
and a receiptRequest. The receiptRequest which is a SimpleReference structure indicates the application endpoint,
interface used for notification of delivery receipt and a correlator that uniquely identifies the sending request. By
invoking this operation with the optional receiptRequest part the application requires to receive the notification of the
status of the message delivery.
If the notification mechanism is not supported by a network a fault (SVC0283) will be returned to the application and
the message will not be sent to the addresses specified. Notification to the application is done by invoking the
notifyMessageDeliveryReceipt operation at the endpoint specified in receiptRequest.
The correlator provided in the receiptRequest must be unique for this Web Service and application at the time the
notification is initiated, otherwise a ServiceException (SVC0005) will be returned to the application.
8.1.1.1 Input message: sendMessageRequest
Part name Part type Optional Description
addresses xsd:anyURI [0.unbounded] No Destination addresses for the Message.
senderAddress xsd:string Yes Message sender address. This parameter is not
rd
allowed for all 3 party providers. Parlay X server
needs to handle this according to a SLA for the
specific application and its use can therefore result in
a PolicyException.
subject xsd:string
...
SLOVENSKI STANDARD
SIST ES 202 391-5 V1.3.1:2008
01-september-2008
2GSUWLGRVWRSGRVWRULWYH 26$ 6SOHWQHVWRULWYH3DUOD\;GHO
9HþSUHGVWDYQRVWQRVSRURþDQMH 3DUOD\;
Open Service Access (OSA) - Parlay X Web Services - Part 5: Multimedia Messaging
(Parlay X 2)
Ta slovenski standard je istoveten z: ES 202 391-5 Version 1.3.1
ICS:
35.100.01 Medsebojno povezovanje Open systems
odprtih sistemov na splošno interconnection in general
SIST ES 202 391-5 V1.3.1:2008 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST ES 202 391-5 V1.3.1:2008
---------------------- Page: 2 ----------------------
SIST ES 202 391-5 V1.3.1:2008
ETSI ES 202 391-5 V1.3.1 (2008-05)
ETSI Standard
Open Service Access (OSA);
Parlay X Web Services;
Part 5: Multimedia Messaging
(Parlay X 2)
�
---------------------- Page: 3 ----------------------
SIST ES 202 391-5 V1.3.1:2008
2 ETSI ES 202 391-5 V1.3.1 (2008-05)
Reference
RES/TISPAN-01056-05-OSA
Keywords
API, OSA, service
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2008.
© The Parlay Group 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
---------------------- Page: 4 ----------------------
SIST ES 202 391-5 V1.3.1:2008
3 ETSI ES 202 391-5 V1.3.1 (2008-05)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.6
2 References.6
2.1 Normative references.6
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.7
4 Detailed service description .7
5 Namespaces.9
6 Sequence diagrams.9
6.1 Send picture.9
6.2 Send WAP Push message.10
7 XML Schema data type definition .11
7.1 DeliveryStatus enumeration.11
7.2 MessagePriority enumeration.11
7.3 DeliveryInformation structure.12
7.4 MessageReference structure.12
7.5 MessageURI structure.12
8 Web Service interface definition.12
8.1 Interface: SendMessage.12
8.1.1 Operation: sendMessage.12
8.1.1.1 Input message: sendMessageRequest.13
8.1.1.2 Output message: sendMessageResponse.13
8.1.1.3 Referenced faults.13
8.1.2 Operation: getMessageDeliveryStatus.14
8.1.2.1 Input message: getMessageDeliveryStatusRequest .14
8.1.2.2 Output message: getMessageDeliveryStatusResponse .14
8.1.2.3 Referenced faults.14
8.2 Interface: ReceiveMessage.14
8.2.1 Operation: getReceivedMessages.14
8.2.1.1 Input message: getReceivedMessagesRequest.15
8.2.1.2 Output message: getReceivedMessagesResponse.15
8.2.1.3 Referenced faults.15
8.2.2 Operation: getMessageURIs.15
8.2.2.1 Input message: getMessageURIsRequest.15
8.2.2.2 Output message: getMessageURIsResponse.15
8.2.2.3 Referenced faults.15
8.2.3 Operation: getMessage.16
8.2.3.1 Input message: getMessageRequest .16
8.2.3.2 Output message: getMessageResponse.16
8.2.3.3 Referenced faults.16
8.3 Interface: MessageNotification.16
8.3.1 Operation: notifyMessageReception.16
8.3.1.1 Input message: notifyMessageReceptionRequest .16
8.3.1.2 Output message: notifyMessageReceptionResponse.17
8.3.1.3 Referenced faults.17
8.3.2 Operation: notifyMessageDeliveryReceipt.17
8.3.2.1 Input message: notifyMessageDeliveryReceiptRequest .17
8.3.2.2 Output message: notifyMessageDeliveryReceiptResponse .17
8.3.2.3 Referenced faults.17
8.4 Interface: MessageNotificationManager .17
8.4.1 Operation: startMessageNotification.18
ETSI
---------------------- Page: 5 ----------------------
SIST ES 202 391-5 V1.3.1:2008
4 ETSI ES 202 391-5 V1.3.1 (2008-05)
8.4.1.1 Input message: startMessageNotificationRequest.18
8.4.1.2 Output message: startMessageNotificationResponse.18
8.4.1.3 Referenced Faults.18
8.4.2 Operation: stopMessageNotification.18
8.4.2.1 Input message: stopMessageNotificationRequest .19
8.4.2.2 Output message: stopMessageNotificationResponse.19
8.4.2.3 Referenced Faults.19
9 Fault definitions.19
9.1 ServiceException.19
9.1.1 Void.19
9.1.2 SVC0283: Delivery Receipt Notification not supported.19
10 Service policies .19
Annex A (normative): WSDL for Multimedia Messaging.20
Annex B (informative): Bibliography.21
History .22
ETSI
---------------------- Page: 6 ----------------------
SIST ES 202 391-5 V1.3.1:2008
5 ETSI ES 202 391-5 V1.3.1 (2008-05)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Standard (ES) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
The present document is part 5 of a multi-part deliverable covering Open Service Access (OSA); Parlay X
Web Services, as identified below:
Part 1: "Common";
Part 2: "Third Party Call";
Part 3: "Call Notification";
Part 4: "Short Messaging";
Part 5: "Multimedia Messaging";
Part 6: "Payment";
Part 7: "Account Management";
Part 8: "Terminal Status";
Part 9: "Terminal Location";
Part 10: "Call Handling";
Part 11: "Audio Call";
Part 12: "Multimedia Conference";
Part 13: "Address List Management";
Part 14: "Presence".
The present document has been defined jointly between ETSI, The Parlay Group (http://www.parlay.org) and the 3GPP.
The present document forms part of the Parlay X 2.2 set of specifications.
The present document is equivalent to 3GPP TS 29.199-05 V6.8.0 (Release 6).
ETSI
---------------------- Page: 7 ----------------------
SIST ES 202 391-5 V1.3.1:2008
6 ETSI ES 202 391-5 V1.3.1 (2008-05)
1 Scope
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, i.e. 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.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably,
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the
method of access to the referenced document and the full network address, with the same punctuation and use of upper
case and lower case letters.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] W3C Recommendation (2 May 2001): "XML Schema Part 2: Datatypes".
NOTE: Available at: http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.
ETSI
---------------------- Page: 8 ----------------------
SIST ES 202 391-5 V1.3.1:2008
7 ETSI ES 202 391-5 V1.3.1 (2008-05)
[2] ETSI ES 202 391-1: "Open Service Access (OSA); Parlay X Web Services; Part 1: Common
(Parlay X 2)".
[3] W3C Note (11 December 2000): "SOAP Messages with Attachments".
NOTE: Available at: http://www.w3.org/TR/SOAP-attachments.
[4] IETF RFC 2822: "Internet Message Format".
NOTE: Available at: http://www.ietf.org/rfc/rfc2822.txt
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 202 391-1 [2] and the following apply:
Whitespace: See definition for CFWS as defined in RFC 2822 [4].
3.2 Abbreviations
For the purposes of the present document, the abbreviations given 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
4 Detailed service description
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 (e.g. 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;
e.g. 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 (the present document), 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.
ETSI
---------------------- Page: 9 ----------------------
SIST ES 202 391-5 V1.3.1:2008
8 ETSI ES 202 391-5 V1.3.1 (2008-05)
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.
Multimedia
Stock Quote
Message Web
Stock Quote MMSC -X
Web Service
Service 4
Web Service component
Parlay X I/F
MMS-C
MMSC
MM7 VASP
Interface
1
3
5
…… .
content1 =get StockQuote ()
….
Retrieve
user Profile
Mobile network
….
content
messageId= sendMessage( )
1
….
2
6
status= getMessageDeliveryStatus (messageId)
if status=Message_Waiting
….
fi
User
…
profile
content2 =get StockQuote ()
messageId= sendMessage ( content2 )
Figure 1: Multimedia Messaging Scenario
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.
ETSI
---------------------- Page: 10 ----------------------
SIST ES 202 391-5 V1.3.1:2008
9 ETSI ES 202 391-5 V1.3.1 (2008-05)
Figure 2: WAP Push scenario
5 Namespaces
The SendMessage interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/multimedia_messaging/send/v2_5
The ReceiveMessage interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/multimedia_messaging/receive/v2_5
The MessageNotification interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/multimedia_messaging/notification/v2_4
The MessageNotificationManager interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/multimedia_messaging/notification_manager/v2_6
The data types are defined in the namespace:
http://www.csapi.org/schema/parlayx/multimedia_messaging/v2_4
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.
6 Sequence diagrams
6.1 Send picture
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.
ETSI
---------------------- Page: 11 ----------------------
SIST ES 202 391-5 V1.3.1:2008
10 ETSI ES 202 391-5 V1.3.1 (2008-05)
: End User : Online Photo : Send MMS
Album Web Service
User logs on
User selects photo to send
User fills in send information
Send multimedia message
Message identifier
Short wait
Get message status
Status
Acknowledgement page
Figure 3
6.2 Send WAP Push message
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.
ETSI
---------------------- Page: 12 ----------------------
SIST ES 202 391-5 V1.3.1:2008
11 ETSI ES 202 391-5 V1.3.1 (2008-05)
Service Content
Send MMS Mobile
provider
Web Service Phone
Add
attachments
Send multimedia message
Message identifier
Link sent to phone
Short wait Phone
Get message status processes
message
Status
Access
link
User enjoys
content
Figure 4
7 XML Schema data type definition
7.1 DeliveryStatus enumeration
List of delivery status values.
Enumeration value Description
DeliveredToNetwork Successful delivery to the network enabler responsible for distributing the multimedia
message further in the network.
DeliveryUncertain Delivery status unknown: e.g. 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.
DeliveryNotificationNot Unable to provide delivery receipt notification. The notifyMessageDeliveryReceipt
Supported operation will provide "DeliveryNotificationNotSupported" to indicate that delivery
receipt for the specified address in a sendMessageRequest message is not
supported.
7.2 MessagePriority enumeration
List of delivery priority values.
Enumeration value Description
Default Default message priority
Low Low message priority
Normal Normal message priority
High High message priority
ETSI
---------------------- Page: 13 ----------------------
SIST ES 202 391-5 V1.3.1:2008
12 ETSI ES 202 391-5 V1.3.1 (2008-05)
7.3 DeliveryInformation structure
Delivery status information.
Element name Element type Optional Description
address xsd:anyURI No Address associated with the delivery status. The address field
is coded as a URI.
deliveryStatus DeliveryStatus No Indicates delivery status for the destination address.
7.4 MessageReference structure
Message information.
Element name Element type Optional Description
messageIdentifier xsd:string Yes 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 xsd:string No Number associated with the invoked Message service, i.e. the
ActivationNumber destination address used by the terminal to send the message.
senderAddress xsd:anyURI No Indicates message sender address.
subject xsd:string Yes If present, indicates the subject of the received message. This
parameter will not be used for SMS services.
priority MessagePriority No The priority of the message: default is Normal.
message xsd:string Yes 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 Yes Time when message was received by operator
7.5 MessageURI structure
Message location information.
Element name Element type Optional Description
bodyText xsd:string Yes Contains the message body if it is encoded as ASCII text.
fileReferences xsd:anyURI [0.unbounded] Yes This is an array of URI references to all the attachments in
the Multimedia message. These are URIs to different files,
e.g. GIF pictures or pure text files.
8 Web Service interface definition
8.1 Interface: SendMessage
Operations to send messages and check status on sent messages.
8.1.1 Operation: 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, i.e. using
getMessageDeliveryStatus to see if the message has been delivered or not. The content is sent as one or more
attachments as specified in SOAP Messages with Attachments [3].
addresses may include group URIs as defined in the Address List Management specification. If groups are not
supported, a fault (POL0006) will be returned to the application.
ETSI
---------------------- Page: 14 ----------------------
SIST ES 202 391-5 V1.3.1:2008
13 ETSI ES 202 391-5 V1.3.1 (2008-05)
Optionally the application can also indicate the sender address (senderAddress), i.e. the string that is displayed on the
user's terminal as the originator of the message, the message priority, the message subject, the charging information
and a receiptRequest. The receiptRequest which is a SimpleReference structure indicates the application endpoint,
interface used for notification of delivery receipt and a correlator that uniquely identifies the sending request. By
invoking this operation with the optional receiptRequest part the application requires to receive the notification of the
status of the message delivery.
If the notification mechanism i
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.