ETSI TR 102 397-5-1-2005 Open Service Access (OSA) Mapping of Parlay X Web Services to Parlay OSA APIs Part 5 Multimedia Messaging Mapping Sub-part 1 Mapping to User Interaction (V.pdf

1、 ETSI TR 102 397-5-1 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 1: Mapping to User InteractionETSI ETSI TR 102 397-5-1 V1.1.1 (2005-12) 2 Reference DTR/TISPAN-01021-05-01-OSA Keywords AP

2、I, 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 presen

3、t 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

4、 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 ot

5、her 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 b

6、y 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 Members. T

7、IPHONTMand 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-1 V1.1.1 (2005-12) 3 Contents Intellectual Property R

8、ights4 Foreword.4 1 Scope 5 2 References 5 3 Definitions and abbreviations.5 3.1 Definitions5 3.2 Abbreviations .5 4 Mapping Description6 5 Sequence Diagrams 6 5.1 Send Multimedia Message to One or More Addresses.6 5.2 Notification of Multimedia Message Reception and Retrieval 9 6 Detailed Mapping I

9、nformation.11 6.1 Operations 11 6.1.1 sendMessage .11 6.1.1.1 Mapping to IpUIManager.createNotification11 6.1.1.2 Mapping to IpUIManager.createUI .11 6.1.1.3 Mapping to IpUI.sendInfoAndCollectReq.12 6.1.2 getMessageDeliveryStatus13 6.1.2.1 Mapping from IpAppUI.sendInfoAndCollectRes .13 6.1.2.2 Mappi

10、ng from IpAppUI.sendInfoAndCollectErr .13 6.1.2.3 Mapping from IpAppUIManager.reportEventNotification14 6.1.3 startMessageNotification 14 6.1.3.1 Mapping to IpUIManager.createNotification14 6.1.4 notifyMessageReception.15 6.1.4.1 Mapping from IpAppUIManager.reportEventNotification15 6.1.5 getReceive

11、dMessages .16 6.1.6 getMessageURIs .16 6.1.7 getMessage .16 6.1.8 stopMessageNotification 16 6.1.8.1 Mapping to IpUIManager.destroyNotification16 6.2 Exceptions 16 7 Additional Notes 16 History 17 ETSI ETSI TR 102 397-5-1 V1.1.1 (2005-12) 4 Intellectual Property Rights IPRs essential or potentially

12、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 n

13、otified 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

14、 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 Telecommunications and I

15、nternet converged Services and Protocols for Advanced Networking (TISPAN). The present document is part 5, sub-part 1, 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, as identified below

16、: 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: “Payment Mapping“; Part 7

17、: “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“. The present docu

18、ment has been defined jointly between ETSI, The Parlay Group (http:/www.parlay.org) and the 3GPP. ETSI ETSI TR 102 397-5-1 V1.1.1 (2005-12) 5 1 Scope The Parlay X Web Services provide powerful yet simple, highly abstracted, imaginative, telecommunications functions that application developers and th

19、e 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 standardized interface, i.e. the Parlay/OSA APIs.

20、The present document is part 5, sub-part 1, 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 User Interaction Service Capability Feature (SCF). 2 References For the pur

21、poses of this Technical Report (TR) the following references apply: 1 ETSI TR 121 905: “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Vocabulary for 3GPP Specifications (3GPP TR 21.905)“. 2 W3C Recommendation (2 May 2001): “XML Schema Part

22、2: Datatypes“. NOTE: Available at http:/www.w3.org/TR/2001/REC-xmlschema-2-20010502/ 3 ETSI TR 102 397-1: “Open Service Access (OSA); Mapping of Parlay X Web Services to Parlay/OSA APIs; Part 1: Common Mapping“. 4 W3C Note (11 December 2000): “SOAP Messages with Attachments“. NOTE: Available at http

23、:/www.w3.org/TR/SOAP-attachments 5 ETSI TS 123 140: “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Multimedia Messaging Service (MMS); Functional description; Stage 2 (3GPP TS 23.140)“. 6 IETF RFC 2822: “Internet Message Format“. NOTE: Avai

24、lable 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 TR 102 397-1 3 and the following apply: Shortcode: Short telephone number, usually 4 to 6 digits long. This is represented by the t

25、el: URI defined in TR 102 397-1 3. Whitespace: See definition for CFWS as defined in RFC 2822 6. 3.2 Abbreviations For the purposes of the present document, the abbreviations given in TR 102 397-1 3 and the following apply: MMS Multimedia Messaging Service SMS Short Message Service ETSI ETSI TR 102

26、397-5-1 V1.1.1 (2005-12) 6 4 Mapping Description The Multimedia Messaging capability can be implemented with the Parlay/OSA User Interaction SCF. It is applicable to ETSI OSA 1.x/2.x/3.x, Parlay/OSA 3.x/4.x/5.x and 3GPP Releases 4.x/5.x/6.x. 5 Sequence Diagrams 5.1 Send Multimedia Message to One or

27、More Addresses This describes where an application sends a multimedia message to one or more addresses. 1. Prior to processing any sendMessageRequest messages from the application, the web service creates an event notification with criteria identifying the application (OriginatingAddress) and the te

28、rminal delivery related states (ServiceCode). 2. 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. Ot

29、herwise, a sendMessageResponse message is returned to the application containing a unique identifier for this multimedia delivery request and processing continues as described below. 3. The web service resolves all group addresses in the addresses part of the sendMessageRequest message to individual

30、 destination addresses. The web service creates a UI session for each individual destination address in the request. 4. The web service sends the message to each individual destination address and requests a message identifier (e.g. a network tracking number) using the sendInfoAndCollectReq method.

31、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 each individual destination address. At this stage, the status return

32、ed for each address is either MessageWaiting or, in the event of an error, DeliveryImpossible. 6. The web service processes an invocation of a sendInfoAndCollectRes method for each individual destination address, which contains a message identifier (e.g. a network tracking number). 7. After the web

33、service processes the sendInfoAndCollectRes method invocation for a destination address, it releases the associated UI session objects created in step 3. 8. The application can invoke the getMessageDeliveryStatus operation. At this stage, the status returned for each individual destination address i

34、s one of the following: - MessageWaiting, if the sendInfoAndCollectRes method has not yet been invoked. - DeliveryImpossible, in the event an error occurred. - DeliveryUncertain, otherwise. 9. The web service processes an invocation of a reportEventNotification method containing the message identifi

35、er (i.e. as received by the web service in step 6), the terminal delivery related status and the sent message. This method notifies the application of an occurred network event matching specific terminal delivery related status criteria, which were previously installed with an invocation (in step 1)

36、 of the createNotification method. 10. RESERVED FOR FUTURE USE If the receiptRequest 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 app

37、lication of the final status of the message delivery to an individual destination address. 11. The web service releases the associated UI session object created in step 9. ETSI ETSI TR 102 397-5-1 V1.1.1 (2005-12) 7 12. The application can invoke the getMessageDeliveryStatus operation. At this stage

38、, the status returned for each individual destination address is one of the following: - Delivered, if this status is reported by the reportEventNotification method. - MessageWaiting, if the sendInfoAndCollectRes method has not yet been invoked. - DeliveryImpossible, in the event an error occurred.

39、- DeliveryUncertain, otherwise. ETSI ETSI TR 102 397-5-1 V1.1.1 (2005-12) 8 Application Multimedia Messaging IpAppUI Manager IpAppUI IpUI Manager IpUI 2a: sendMessageRequest “new“ 3: createUI() “new“ 2b: sendMessageResponse 4: sendInfoAndCollectReq() 6: sendInfoAndCollectRes() “forward event“ FOR FU

40、TURE USE 10.1a: notifyMessage DeliveryReceiptRequest 8a: getMessageDeliveryStatusRequest IpAppUI IpAppUI IpUI 1: createNotification() “destroy“ 7: release() 9.1: reportEventNotification() “forward event“ 11.1: release() “new“ FOR FUTURE USE 10.1b: notifyMessage DeliveryReceiptResponse 8b: getMessage

41、DeliveryStatusResponse FOR FUTURE USE 10.xa: notifyMessage DeliveryReceiptRequest 9.x: reportEventNotification() “forward event“ 11.x: release() “new“ 12a: getMessageDeliveryStatusRequest 12b: getMessageDeliveryStatusResponse 5a: getMessageDeliveryStatusRequest 5b: getMessageDeliveryStatusResponse F

42、OR FUTURE USE 10.xb: notifyMessage DeliveryReceiptResponse IpUI Figure 1 ETSI ETSI TR 102 397-5-1 V1.1.1 (2005-12) 9 5.2 Notification of Multimedia Message Reception and Retrieval 1. The application registers for the reception of multimedia messages by invoking startMessageNotification. The request

43、includes event criteria consisting of a value for the multimedia message destination address (the messageServiceActivationNumber part) and an optional text string for matching against the first word of the subject of the multimedia message or the first word in the text part of the multimedia message

44、 (the criteria part); also a URI for a Web Service implementing the MessageNotification interface on the client application side, and a correlation value for identifying this event registration request. - Note that the application may also register offline for the reception of multimedia messages: i

45、.e. without using the Parlay X interface and the startMessageNotification operation. The registration request should at a minimum specify the message destination address. The request may also specify a URI for a Web Service implementing the MessageNotification interface on the client application sid

46、e and/or the optional text string criteria. The registration request is assigned a unique registration identifier. 2. A check is made within the web service to see if a notification for the given multimedia message destination address is active. If no notification is active, then the Multimedia Mess

47、aging web service requests that a notification be created by the UI SCS; note that the optional text string criteria (for matching against the first word in the message subject or body) is not sent to the UI SCS. Otherwise a notification is already active and the request is not made. 3. The UI SCS s

48、ends a reportEventNotification containing the message identifier, the message delivery status and the received message. The web service stores the multimedia message information. 4. The web service releases the UI session within the notification and verifies the event satisfies all criteria specifie

49、d in step 1, including matching the first word of the message subject or body against the value of the optional text string criteria. If the event is verified, then it stores the received message and notifies the application (step 5); else the event is invalid (step 5 is skipped) and it discards the received message. 5. The web service notifies the application of the received multimedia message information by invoking the notifyMessageReception operation on the application Web Service. Note that if the multimedia message is pure ASCII text, then the