1、 ETSI TR 102 397-4-1 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 1: Mapping to User InteractionETSI ETSI TR 102 397-4-1 V1.1.1 (2005-12) 2 Reference DTR/TISPAN-01021-04-01-OSA Keywords API, OS
2、A, 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 present doc
3、ument 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 disp
4、ute, 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 E
5、TSI 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 wri
6、tten 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. TIPHON
7、TMand 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-1 V1.1.1 (2005-12) 3 Contents Intellectual Property Rights
8、4 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 Short Message to One or More Addresses 6 5.2 Notification of Short Message Reception and Retrieval 9 6 Detailed Mapping Information.11 6
9、.1 Operations 11 6.1.1 sendSms 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 sendSmsLogo12 6.1.3 sendSmsRingtone .13 6.1.4 getSmsDeliveryStatus.13 6.1.4.1 Mapping from IpAppUI.sendInfoAndColle
10、ctRes .13 6.1.4.2 Mapping from IpAppUI.sendInfoAndCollectErr .14 6.1.4.3 Mapping from IpAppUIManager.reportEventNotification14 6.1.5 notifySmsDeliveryReceipt14 6.1.5.1 Mapping from IpAppUI.sendInfoAndCollectErr .15 6.1.5.2 Mapping from IpAppUIManager.reportEventNotification15 6.1.6 startSmsNotificat
11、ion .15 6.1.6.1 Mapping to IpUIManager.createNotification15 6.1.7 notifySmsReception16 6.1.7.1 Mapping from IpAppUIManager.reportEventNotification16 6.1.8 getReceivedSms17 6.1.9 stopSMSNotification 17 6.1.9.1 Mapping to IpUIManager.destroyNotification17 6.2 Exceptions 17 7 Additional Notes 17 Histor
12、y 18 ETSI ETSI TR 102 397-4-1 V1.1.1 (2005-12) 4 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
13、 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
14、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
15、. 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 1, of a multi-part deliverable providing an informative mapping of Parlay X
16、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-part 1: “Mapping to User Interaction“; Sub-part 2: “
17、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“; Part 11: “Audio Call Mapping“; Part 12: “Multimedia Co
18、nference 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-1 V1.1.1 (2005-12) 5 1 Scope The Parlay X Web Services provide powerful
19、 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 define an architecture that enables application develo
20、pers 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 1, of an informative mapping of Parlay X Web Services to Parlay/OSA APIs. The present document specifies the mapping of the Parlay X Short Messaging We
21、b Service to the Parlay/OSA User Interaction 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+); Universal Mobile Telecommunications System (UMTS); Voc
22、abulary 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 of Parlay X Web Services to Parlay/OSA APIs; Part 1: Co
23、mmon 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 Message Format“. NOTE: Available at http:/www.ietf.org/rfc/r
24、fc2822.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 tel: URI defined in TR 102 397-1 3
25、. 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: SMS Short Message Service ETSI ETSI TR 102 397-4-1 V1.1.1 (2005-12) 6 4 Mapping Description The Short Messagi
26、ng 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 Short Message to One or More Addresses This describes where an application sends a short message to
27、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 the diagram below replace sendSms with sendSmsLogo or sendSmsRingtone as appropriate. 1. Prior to processing any send
28、SmsRequest messages from the application, the web service creates an event notification with criteria identifying the application (OriginatingAddress) and the terminal delivery related states (ServiceCode). 2. The application requests the sending of a short message to multiple addresses using the se
29、ndSms operation. If the contents of the sendSmsRequest message are invalid for any reason, the appropriate service or policy exception is thrown. Otherwise, a sendSmsResponse message is returned to the application containing a unique identifier for this SMS delivery request and processing continues
30、as described below. 3. The web service resolves all group addresses in the addresses part of the sendSmsRequest message to individual 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 indiv
31、idual destination address and requests a message identifier (e.g. a network tracking number) using the sendInfoAndCollectReq method. 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
32、 this message to obtain 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 a sendInfoAndCollectRes method for
33、 each individual destination address, which contains a message identifier (e.g. a network tracking number). 7. After the web service processes the sendInfoAndCollectRes method invocation for a destination address, it releases the associated UI session objects created in step 3. 8. The application ca
34、n invoke the getSmsDeliveryStatus operation. At this stage, the status returned for each individual destination address is one of the following: - MessageWaiting, if the sendInfoAndCollectRes method has not yet been invoked. - DeliveryImpossible, in the event an error occurred. - DeliveredToNetwork,
35、 if the sendInfoAndCollectRes method has been invoked. - DeliveryUncertain, otherwise. 9. The web service processes an invocation of a reportEventNotification method containing the message identifier (i.e. as received by the web service in step 6), the terminal delivery related status and the sent m
36、essage. 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) of the createNotification method. 10. If the receiptRequest part of the associated, original sendSmsRe
37、quest 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 address. ETSI ETSI TR 102 397-4-1 V1.1.1 (2005-12) 7 11.
38、The web service releases the associated UI session object created in step 9. 12. The application can invoke the getSmsDeliveryStatus operation. At this stage, the status returned for each individual destination address is one of the following: - DeliveredToTerminal, if this status is reported by the
39、 reportEventNotification method. - MessageWaiting, if the sendInfoAndCollectRes method has not yet been invoked. - DeliveryImpossible, in the event an error occurred. - DeliveredToNetwork, if the sendInfoAndCollectRes method, but not the reportEventNotification method, has been invoked. - DeliveryUn
40、certain, otherwise. ETSI ETSI TR 102 397-4-1 V1.1.1 (2005-12) 8 Application Short Messaging IpAppUI Manager IpAppUI IpUI Manager IpUI 2a: sendSmsRequest “new“ 3: createUI() “new“ 2b: sendSmsResponse 4: sendInfoAndCollectReq() 6: sendInfoAndCollectRes() “forward event“ 10.1a: notifySmsDelivery Receip
41、tRequest 8a: getSmsDeliveryStatusRequest IpAppUI IpAppUI IpUI 1: createNotification() “destroy“ 7: release() 9.1: reportEventNotification() “forward event“ 11.1: release() “new“ 10.1b: notifySmsDelivery ReceiptResponse 8b: getSmsDeliveryStatusResponse 10.xa: notifySmsDelivery ReceiptRequest 9.x: rep
42、ortEventNotification() “forward event“ 11.x: release() “new“ 12a: getSmsDeliveryStatusRequest 12b: getSmsDeliveryStatusResponse 5a: getSmsDeliveryStatusRequest 5b: getSmsDeliveryStatusResponse 10.xb: notifySmsDelivery ReceiptResponse IpUI Figure 1 ETSI ETSI TR 102 397-4-1 V1.1.1 (2005-12) 9 5.2 Noti
43、fication of Short Message Reception and Retrieval 1. The application registers for the reception of short messages by invoking startSmsNotification. The request includes event criteria consisting of a value for the short message destination address (the smsServiceActivationNumber part) and an option
44、al text string for matching against the first word of the message body (the criteria part); also a URI for a Web Service implementing the SmsNotification interface on the client application side, and a correlation value for identifying this event registration request. - Note that the application may
45、 also register offline for the reception of short messages: i.e. without using the Parlay X interface and the startSmsNotification 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 Sm
46、sNotification interface on the client application side 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 short message destination address is active. If no
47、notification is active, then the Short Messaging 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 SMS body) is not sent to the UI SCS. Otherwise a notification is already active and the request
48、is not made. 3. The UI SCS sends a reportEventNotification containing the message identifier, the message delivery status and the received message. The web service stores the short message information. 4. The web service releases the UI session within the notification and verifies the event satisfie
49、s all criteria specified in step 1, including matching the first word of the message 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 short message information by invoking the notifySmsReception operation on the application Web Service. 6. Steps 3, 4 and 5 are repeated for any received message event ma
