1、 ETSI TR 102 397-5-2 V1.1.1 (2005-12)Technical Report Open Service Access (OSA);Mapping of Parlay X Web Services to Parlay/OSA APIs;Part 5: Multimedia Messaging Mapping;Sub-part 2: Mapping to Multi-Media MessagingETSI ETSI TR 102 397-5-2 V1.1.1 (2005-12) 2 Reference DTR/TISPAN-01021-05-02-OSA Keywor
2、ds 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 enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the p
3、resent 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 ca
4、se 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 a
5、nd 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 authori
6、zed by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2005. The Parlay Group 2005. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Membe
7、rs. TIPHONTMand the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TR 102 397-5-2 V1.1.1 (2005-12) 3 Contents Intellectual Prope
8、rty Rights5 Foreword.5 1 Scope 6 2 References 6 3 Definitions and abbreviations.6 3.1 Definitions6 3.2 Abbreviations .7 4 Mapping Description7 5 Sequence Diagrams 8 5.1 Send Multimedia Message to One or More Addresses (Messaging Paradigm)8 5.2 Notification of Multimedia Message Reception and Retriev
9、al (Messaging Paradigm) .11 5.3 Send Multimedia Message to One or More Addresses (Mailbox Paradigm) .13 5.4 Notification of Multimedia Message Reception and Retrieval (Mailbox Paradigm) .16 6 Detailed Mapping Information.19 6.1 Operations (Messaging Paradigm) .19 6.1.1 sendMessage .19 6.1.1.1 Mappin
10、g to IpMMMManager.openMMM .19 6.1.1.2 Mapping to IpMMM.sendMessageReq .20 6.1.2 getMessageDeliveryStatus21 6.1.2.1 Mapping from IpAppMMM.sendMessageRes21 6.1.2.2 Mapping from IpAppMMM.sendMessageErr21 6.1.2.3 Mapping from IpAppMMM.messageStatusReport22 6.1.2.4 Mapping to IpMMM.queryStatusReq .22 6.1
11、.2.5 Mapping from IpAppMMM.queryStatusRes22 6.1.2.6 Mapping from IpAppMMM.queryStatusErr23 6.1.3 startMessageNotification 23 6.1.3.1 Mapping to IpMMMManager.createNotification.23 6.1.4 notifyMessageReception.23 6.1.4.1 Mapping from IpAppMMMManager.reportNotification .24 6.1.4.2 Mapping from TpNewMes
12、sageArrivedInfo24 6.1.4.3 Mapping from IpAppMMM.messageReceived.25 6.1.5 getReceivedMessages .25 6.1.6 getMessageURIs .25 6.1.7 getMessage .25 6.1.8 stopMessageNotification 25 6.1.8.1 Mapping to IpMMMManager.destroyNotification.26 6.2 Operations (Mailbox Paradigm) .26 6.2.1 sendMessage .26 6.2.1.1 M
13、apping to IpMMMManager.openMailbox26 6.2.1.2 Mapping to IpMailbox.putMessageReq27 6.2.2 getMessageDeliveryStatus27 6.2.2.1 Mapping from IpAppMailbox.putMessageRes.28 6.2.2.2 Mapping from IpAppMailbox.putMessageErr.28 6.2.2.3 Mapping to IpMailbox.getMessageInfoPropertiesReq.28 6.2.2.4 Mapping from Ip
14、AppMailbox.getMessageInfoPropertiesRes.29 6.2.2.5 Mapping from IpAppMailbox.getMessageInfoPropertiesErr.29 6.2.3 startMessageNotification 29 6.2.3.1 Mapping to IpMMMManager.createNotification.29 6.2.4 notifyMessageReception.30 6.2.4.1 Mapping from IpAppMMMManager.reportNotification .31 6.2.4.2 Mappi
15、ng to IpMMMManager.openMailbox31 6.2.4.3 Mapping to IpMailbox.getMessageContentReq32 6.2.4.4 Mapping from IpAppMailbox.getMessageContentRes32 ETSI ETSI TR 102 397-5-2 V1.1.1 (2005-12) 4 6.2.4.5 Mapping to IpMailbox.getMessageBodyPartsReq.33 6.2.4.6 Mapping from IpAppMailbox.getMessageBodyPartsRes.33
16、 6.2.5 getReceivedMessages .33 6.2.6 getMessageURIs .33 6.2.7 getMessage .33 6.2.8 stopMessageNotification 34 6.2.8.1 Mapping to IpMMMManager.destroyNotification.34 6.3 Exceptions 34 7 Additional Notes 34 History 35 ETSI ETSI TR 102 397-5-2 V1.1.1 (2005-12) 5 Intellectual Property Rights IPRs essent
17、ial 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 potentiall
18、y 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
19、 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 Technical Report (TR) has been produced by ETSI Technical Committee Telec
20、ommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN). The present document is part 5, sub-part 2, of a multi-part deliverable providing an informative mapping of Parlay X Web Services to the Parlay Open Service Access (OSA) APIs and, where applicable, to IMS,
21、as identified below: Part 1: “Common Mapping“; Part 2: “Third Party Call Mapping“; Part 3: “Call Notification Mapping“; Part 4: “Short Messaging Mapping“; Part 5: “Multimedia Messaging Mapping“; Sub-part 1: “Mapping to User Interaction“; Sub-part 2: “Mapping to Multi-Media Messaging“; Part 6: “Payme
22、nt Mapping“; Part 7: “Account Management Mapping“; Part 8: “Terminal Status Mapping“; Part 9: “Terminal Location Mapping“; Part 10: “Call Handling Mapping“; Part 11: “Audio Call Mapping“; Part 12: “Multimedia Conference Mapping“; Part 13: “Address list Management Mapping“; Part 14: “Presence Mapping
23、“. The present document has been defined jointly between ETSI, The Parlay Group (http:/www.parlay.org) and the 3GPP. ETSI ETSI TR 102 397-5-2 V1.1.1 (2005-12) 6 1 Scope The Parlay X Web Services provide powerful yet simple, highly abstracted, imaginative, telecommunications functions that applicatio
24、n developers and the IT community can both quickly comprehend and use to generate new, innovative applications. The Open Service Access (OSA) specifications define an architecture that enables application developers to make use of network functionality through an open standardised interface, i.e. th
25、e Parlay/OSA APIs. The present document is part 5, sub-part 2, of an informative mapping of Parlay X Web Services to Parlay/OSA APIs. The present document specifies the mapping of the Parlay X Multimedia Messaging Web Service to the Parlay/OSA Multi-Media Messaging Service Capability Feature (SCF).
26、2 References For the purposes of this Technical Report (TR) the following references apply: 1 ETSI TR 102 397-1: “Open Service Access (OSA); Mapping of Parlay X Web Services to Parlay/OSA APIs; Part 1: Common Mapping“. 2 IETF RFC 2822: “Internet Message Format“. NOTE: Available at http:/www.ietf.org
27、/rfc/rfc2822.txt 3 W3C Note (11 December 2000): “SOAP Messages with Attachments“. NOTE: Available at http:/www.w3.org/TR/SOAP-attachments 4 IETF RFC 2045: “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies“. NOTE: Available at http:/www.ietf.org/rfc/rfc2045.txt
28、 5 IETF RFC 2046: “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types“. NOTE: Available at http:/www.ietf.org/rfc/rfc2046.txt 6 IETF RFC 2557: “MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)“. NOTE: Available at http:/www.ietf.org/rfc/rfc2557.txt 7 ETSI TR 121 905: “
29、Universal Mobile Telecommunications System (UMTS); Vocabulary for 3GPP Specifications (3GPP TR 21.905)“. 8 W3C Recommendation (2 May 2001): “XML Schema Part 2: Datatypes“. 9 ETSI TS 123 140: “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Mu
30、ltimedia Messaging Service (MMS); Functional description; Stage 2 (3GPP TS 23.140)“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in TR 102 397-1 1 and the following apply: Shortcode: Short telephone number, usually 4 to 6
31、digits long. This is represented by the tel: URI defined in TR 102 397-1 1. ETSI ETSI TR 102 397-5-2 V1.1.1 (2005-12) 7 Whitespace: See definition for CFWS as defined in RFC 2822 2. 3.2 Abbreviations For the purposes of the present document, the abbreviations given in TR 102 397-1 1 and the followin
32、g apply: MMS Multimedia Messaging Service 4 Mapping Description The Multimedia Messaging capability can be implemented with the Parlay/OSA Multi-Media Messaging SCF. It is applicable to ETSI OSA 3.x, Parlay/OSA 5.x and 3GPP Release 6.x. The following tables list the versions of the applicable mappin
33、g source documents, for both the ETSI/Parlay and the 3GPP specification sets. Table 1: ETSI/Parlay Mapping Source Documents Parlay X 2.1 Web Services Parlay 3.5 Parlay 4.3 Parlay 5.1 Draft ES 202 391-5 V1.1.3 n/a n/a Draft ES 203 915-15 V0.0.4 Table 2: 3GPP Mapping Source Documents Release 6 Parlay
34、X Web Services Release 4 Release 5 Release 6 TS 29.199-5 V6.3.0 n/a n/a TS 29.198-15 V6.2.1 ETSI ETSI TR 102 397-5-2 V1.1.1 (2005-12) 8 5 Sequence Diagrams 5.1 Send Multimedia Message to One or More Addresses (Messaging Paradigm) This describes where an application sends a multimedia message to one
35、or more addresses. 1. The application requests the sending of a multimedia message to multiple addresses using the sendMessage operation. If the contents of the sendMessageRequest message are invalid for any reason, the appropriate service or policy exception is thrown. Otherwise processing continue
36、s as described below. 2. The web service creates a Multi-Media Messaging interface object for this application request (single-shot, page mode); no source or destination address information is provided in the method invocation. If the method invocation fails for any reason, the appropriate service o
37、r policy exception is thrown. Otherwise processing continues as described below. 3. A sendMessageResponse message is returned to the application containing a unique identifier for this message delivery request. 4. The web service invokes the sendMessageReq method on the Multi-Media Messaging interfa
38、ce object to send the message to each individual destination address. 5. The application can invoke the getMessageDeliveryStatus operation at any time after it receives the sendMessageResponse message and use the unique identifier it received in this message to obtain the current delivery status for
39、 each individual destination address. At this stage, the status returned for each address is either MessageWaiting or, in the event of an error, DeliveryImpossible. 6. The web service processes an invocation of the sendMessageRes method indicating that the message has been successfully sent to the d
40、estination address(es). However it does not indicate that the message was delivered or read. 7. The application can invoke the getMessageDeliveryStatus operation. At this stage, the status returned for each individual destination address is one of the following: - DeliveryImpossible, in the event an
41、 error occurred. - DeliveryUncertain, otherwise. 8. The web service processes one or more invocations of the messageStatusReport method, one for each destination address associated with the message, which contains the terminal delivery related status. 9. RESERVED FOR FUTURE USE If the receiptRequest
42、 part of the associated, original sendMessageRequest message was present, and this capability is supported by the web service, then the web service invokes the notifyMessageDeliveryReceipt operation to notify the application of the final status of the message delivery to an individual destination ad
43、dress. 10. The application can invoke the getMessageDeliveryStatus operation. At this stage, the status returned for an individual destination address depends on whether a messageStatusReport method has been invoked for that address. If the method has not been invoked, the delivery status is as desc
44、ribed in step 7. Otherwise this method has been invoked and the delivery status is one of the following: - Delivered, if deliveryReportType parameter value = P_MESSAGE_REPORT_DELIVERED. - DeliveryImpossible, if deliveryReportType parameter value = P_MESSAGE_REPORT_ NOT_DELIVERABLE. - DeliveryUncerta
45、in, if deliveryReportType parameter value = P_MESSAGE_REPORT_ DELIVERY_UNDEFINED. 11. If the web service has not yet received all the requested terminal delivery related status reports, it may optionally invoke the queryStatusReq method to poll the network for this information. ETSI ETSI TR 102 397-
46、5-2 V1.1.1 (2005-12) 9 12. The web service processes an invocation of the queryStatusRes method containing terminal delivery related status for all destination addresses associated with the message. 13. RESERVED FOR FUTURE USE If the receiptRequest part of the associated, original sendMessageRequest
47、 message was present, and this capability is supported by the web service, then the web service invokes the notifyMessageDeliveryReceipt operation to notify the application of the final status of the message delivery to an individual destination address. (However if the delivery status is unchanged
48、from the status previously reported to the application, then the web service does not need to invoke this operation.) 14. The application can invoke the getMessageDeliveryStatus operation. At this stage, the status returned for all associated destination addresses reflects the results provided by th
49、e queryStatusRes method (step 12), i.e.: - Delivered, if deliveryReportType parameter value = P_MESSAGE_REPORT_DELIVERED. - DeliveryImpossible, if deliveryReportType parameter value = P_MESSAGE_REPORT_ NOT_DELIVERABLE. - DeliveryUncertain, if deliveryReportType parameter value = P_MESSAGE_REPORT_ DELIVERY_UNDEFINED. ETSI ETSI TR 102 397-5-2 V1.1.1 (2005-12)10Application Multimedia Messaging IpAppMMM Manager IpAppMMM IpMMM Manager IpMMM 1: sendMessageRequest “new“ 2: openMultiMediaMessaging() “new“ 3: sendMessageResponse 4: sendMessageReq()
