1、 ETSI TR 102 397-4-2 V1.1.1 (2005-12)Technical Report Open Service Access (OSA);Mapping of Parlay X Web Services to Parlay/OSA APIs;Part 4: Short Messaging Mapping;Sub-part 2: Mapping to Multi-Media MessagingETSI ETSI TR 102 397-4-2 V1.1.1 (2005-12) 2 Reference DTR/TISPAN-01021-04-02-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-4-2 V1.1.1 (2005-12) 3 Contents Intellectual Property R
8、ights5 Foreword.5 1 Scope 6 2 References 6 3 Definitions and abbreviations.6 3.1 Definitions6 3.2 Abbreviations .6 4 Mapping description.7 5 Sequence Diagrams 7 5.1 Send Short Message to One or More Addresses (Messaging Paradigm) .7 5.2 Notification of Short Message Reception and Retrieval (Messagin
9、g Paradigm) .10 5.3 Send Short Message to One or More Addresses (Mailbox Paradigm) .12 5.4 Notification of Short Message Reception and Retrieval (Mailbox Paradigm) .15 6 Detailed Mapping Information.18 6.1 Operations (Messaging Paradigm) .18 6.1.1 sendSms 18 6.1.1.1 Mapping to IpMMMManager.openMMM .
10、18 6.1.1.2 Mapping to IpMMM.sendMessageReq .19 6.1.2 sendSmsLogo19 6.1.3 sendSmsRingtone .20 6.1.4 getSmsDeliveryStatus.20 6.1.4.1 Mapping from IpAppMMM.sendMessageRes20 6.1.4.2 Mapping from IpAppMMM.sendMessageErr21 6.1.4.3 Mapping from IpAppMMM.messageStatusReport21 6.1.4.4 Mapping to IpMMM.queryS
11、tatusReq .21 6.1.4.5 Mapping from IpAppMMM.queryStatusRes22 6.1.4.6 Mapping from IpAppMMM.queryStatusErr22 6.1.5 notifySmsDeliveryReceipt22 6.1.5.1 Mapping from IpAppMMM.sendMessageErr23 6.1.5.2 Mapping from IpAppMMM.messageStatusReport23 6.1.5.3 Mapping from IpAppMMM.queryStatusRes24 6.1.6 startSms
12、Notification .24 6.1.6.1 Mapping to IpMMMManager.createNotification .24 6.1.7 notifySmsReception25 6.1.7.1 Mapping from IpAppMMMManager.reportNotification25 6.1.7.2 Mapping from TpNewMessageArrivedInfo25 6.1.7.3 Mapping from IpAppMMM.messageReceived.26 6.1.8 getReceivedSms26 6.1.9 stopSMSNotificatio
13、n 26 6.1.9.1 Mapping to IpMMMManager.destroyNotification .26 6.2 Operations (Mailbox Paradigm) .27 6.2.1 sendSms 27 6.2.1.1 Mapping to IpMMMManager.openMailbox27 6.2.1.2 Mapping to IpMailbox.putMessageReq27 6.2.2 sendSmsLogo28 6.2.3 sendSmsRingtone .28 6.2.4 getSmsDeliveryStatus.28 6.2.4.1 Mapping f
14、rom IpAppMailbox.putMessageRes.29 6.2.4.2 Mapping from IpAppMailbox.putMessageErr.29 6.2.4.3 Mapping to IpMailbox.getMessageInfoPropertiesReq .29 6.2.4.4 Mapping from IpAppMailbox.getMessageInfoPropertiesRes 30 6.2.4.5 Mapping from IpAppMailbox.getMessageInfoPropertiesErr.30 6.2.5 notifySmsDeliveryR
15、eceipt30 ETSI ETSI TR 102 397-4-2 V1.1.1 (2005-12) 4 6.2.5.1 Mapping from IpAppMailbox.putMessageErr.31 6.2.5.2 Mapping from IpAppMailbox.getMessageInfoPropertiesRes 31 6.2.6 startSmsNotification .31 6.2.6.1 Mapping to IpMMMManager.createNotification .32 6.2.7 notifySmsReception32 6.2.7.1 Mapping fr
16、om IpAppMMMManager.reportNotification33 6.2.7.2 Mapping to IpMMMManager.openMailbox33 6.2.7.3 Mapping to IpMailbox.getMessageContentReq.33 6.2.7.4 Mapping from IpAppMailbox.getMessageContentRes.34 6.2.8 getReceivedSms34 6.2.9 stopSMSNotification.34 6.2.9.1 Mapping to IpMMMManager.destroyNotification
17、 .35 6.3 Exceptions 35 7 Additional Notes 35 History 36 ETSI ETSI TR 102 397-4-2 V1.1.1 (2005-12) 5 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 ava
18、ilable 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 ser
19、ver (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 b
20、e, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by ETSI Technical Committee Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN). The present document is part 4, sub-part 2, of a multi-part delive
21、rable 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: Part 1: “Common Mapping“; Part 2: “Third Party Call Mapping“; Part 3: “Call Notification Mapping“; Part 4: “Short Messaging Mapping“; Sub-p
22、art 1: “Mapping to User Interaction“; Sub-part 2: “Mapping to Multi-Media Messaging“; Part 5: “Multimedia Messaging Mapping“; Part 6: “Payment Mapping“; Part 7: “Account Management Mapping“; Part 8: “Terminal Status Mapping“; Part 9: “Terminal Location Mapping“; Part 10: “Call Handling Mapping“; Par
23、t 11: “Audio Call Mapping“; Part 12: “Multimedia Conference Mapping“; Part 13: “Address list Management Mapping“; Part 14: “Presence Mapping“. The present document has been defined jointly between ETSI, The Parlay Group (http:/www.parlay.org) and the 3GPP. ETSI ETSI TR 102 397-4-2 V1.1.1 (2005-12) 6
24、 1 Scope The Parlay X Web Services provide powerful yet simple, highly abstracted, imaginative, telecommunications functions that application developers and the IT community can both quickly comprehend and use to generate new, innovative applications. The Open Service Access (OSA) specifications def
25、ine an architecture that enables application developers to make use of network functionality through an open standardized interface, i.e. the Parlay/OSA APIs. The present document is part 4, sub-part 2, of an informative mapping of Parlay X Web Services to Parlay/OSA APIs. The present document speci
26、fies the mapping of the Parlay X Short Messaging Web Service to the Parlay/OSA Multi-Media Messaging Service Capability Feature (SCF). 2 References For the purposes of this Technical Report (TR) the following references apply: 1 ETSI TR 121 905: “Digital cellular telecommunications system (Phase 2+)
27、; Universal Mobile Telecommunications System (UMTS); Vocabulary for 3GPP Specifications (3GPP TR 21.905)“. 2 W3C Recommendation (2 May 2001): “XML Schema Part 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
28、 of Parlay X Web Services to Parlay/OSA APIs; Part 1: Common Mapping“. 4 ETSI TS 123 040: “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Technical realization of Short Message Service (SMS) (3GPP TS 23.040)“. 5 IETF RFC 2822: “Internet Mess
29、age 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 TR 102 397-1 3 and the following apply: Shortcode: Short telephone number, usually 4 to 6 digits long. This
30、is represented by the tel: URI defined in TR 102 397-1 3. Whitespace: See definition for CFWS as defined in RFC 2822 5. 3.2 Abbreviations For the purposes of the present document, the abbreviations given in TR 102 397-1 3 and the following apply: MMM Multi-Media Messaging SMS Short Message Service U
31、RI Uniform Resource Identifier ETSI ETSI TR 102 397-4-2 V1.1.1 (2005-12) 7 4 Mapping description The Short 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. 5 Sequence Diagrams 5.1 Send Short
32、Message to One or More Addresses (Messaging Paradigm) This describes where an application sends a short message to one or more addresses. The use case is the same whether the message is text, ringtone or a logo, however a different operation on the Parlay X SendSms interface is used for each. For th
33、e diagram below replace sendSms with sendSmsLogo or sendSmsRingtone as appropriate. 1. The application requests the sending of a short message to multiple addresses using the sendSms operation. If the contents of the sendSmsRequest message are invalid for any reason, the appropriate service or polic
34、y exception is thrown. Otherwise processing continues 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 invoca
35、tion fails for any reason, the appropriate service or policy exception is thrown. Otherwise processing continues as described below. 3. A sendSmsResponse message is returned to the application containing a unique identifier for this SMS delivery request. 4. The web service invokes the sendMessageReq
36、 method on the Multi-Media Messaging interface object to send the message to each individual destination address. 5. The application can invoke the getSmsDeliveryStatus operation at any time after it receives the sendSmsResponse message and use the unique identifier it received in this message to ob
37、tain the current delivery status for 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
38、 has been successfully sent to the destination address(es). However it does not indicate that the message was delivered or read. 7. The application can invoke the getSmsDeliveryStatus operation. At this stage, the status returned for each individual destination address is one of the following: - Del
39、iveryImpossible, in the event an error occurred. - DeliveredToNetwork, 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. If the recei
40、ptRequest part of the associated, original sendSmsRequest message was present, and this capability is supported by the web service, then the web service invokes the notifySmsDeliveryReceipt operation to notify the application of the final status of the SMS delivery to an individual destination addre
41、ss. ETSI ETSI TR 102 397-4-2 V1.1.1 (2005-12) 8 10. The application can invoke the getSmsDeliveryStatus 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 in
42、voked, the delivery status is as described in step 7. Otherwise this method has been invoked and the delivery status is one of the following: - DeliveredToTerminal, if deliveryReportType parameter value = P_MESSAGE_REPORT_DELIVERED. - DeliveryImpossible, if deliveryReportType parameter value = P_MES
43、SAGE_REPORT_ NOT_DELIVERABLE. - DeliveryUncertain, 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 netw
44、ork for this information. 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. If the receiptRequest part of the associated, original sendSmsRequest message was present, and
45、 this capability is supported by the web service, then the web service invokes the notifySmsDeliveryReceipt operation to notify the application of the final status of the SMS delivery to an individual destination address. (However if the delivery status is unchanged from the status previously report
46、ed to the application, then the web service does not need to invoke this operation.) 14. The application can invoke the getSmsDeliveryStatus operation. At this stage, the status returned for all associated destination addresses reflects the results provided by the queryStatusRes method (step 12), i.
47、e.: - DeliveredToTerminal, 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
48、 TR 102 397-4-2 V1.1.1 (2005-12)9 Application Short Messaging IpAppMMM Manager IpAppMMM IpMMM Manager IpMMM 1: sendSmsRequest “new“ 2: openMultiMediaMessaging() “new“ 3: sendSmsResponse 4: sendMessageReq() 6: sendMessageRes() “forward event” 8: messageStatusReport() “forward event” 12: queryStatusRe
49、s() “forward event“ 10a: getSmsDeliveryStatusRequest 10b: getSmsDeliveryStatusResponse 11: queryStatusReq() 9b: notifySmsDeliveryReceiptResponse 9a: notifySmsDeliveryReceiptRequest 13b: notifySmsDeliveryReceiptResponse 13a: notifySmsDeliveryReceiptRequest 5a: getSmsDeliveryStatusRequest 5b: getSmsDeliveryStatusResponse 7a: getSmsDeliveryStatusRequest 7b: getSmsDeliveryStatusResponse 14a: getSmsDeliveryStatusRequest 14b: getSmsDeliveryStatusResponse Figure 1 ETSI ETSI TR 102 397-4-2 V1.1.1 (2005-12) 10 5.2 Notification of Short Message Reception and Retri
