SIST ES 202 504-4 V1.1.1:2008
Open Service Access (OSA) - Parlay X Web Services - Part 4: Short Messaging (Parlay X 3)
- Abstract
New edition of ParlayX specification based on requirements in EG 201 988-4, corresponding to 3GPP TS 29.199 Rel-7. The present document is part 4 of the Stage 3 Parlay X 3 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 Short 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.
- Status
- Published
- Publication Date
- 14-Jul-2008
- Technical Committee
- SPN - Services and Protocols for Networks
- Current Stage
- 6060 - National Implementation/Publication (Adopted Project)
- Start Date
- 18-Jun-2008
- Due Date
- 23-Aug-2008
- Completion Date
- 15-Jul-2008
Buy Documents
ETSI ES 202 504-4 V1.1.1 (2008-02) - Open Service Access (OSA); Parlay X Web Services; Part 4: Short Messaging (Parlay X 3)
ETSI ES 202 504-4 V1.1.1 (2008-05) - Open Service Access (OSA); Parlay X Web Services; Part 4: Short Messaging (Parlay X 3)
SIST ES 202 504-4 V1.1.1:2008 is the Short Messaging part of the Parlay X Web Services specification for Open Service Access (OSA). It defines a web service interface for sending, receiving, scheduling, and monitoring SMS messages through standard APIs, for application developers and service providers who want to use network messaging functions without working directly with network-element protocols.
What does SIST ES 202 504-4 V1.1.1:2008 specify?
SIST ES 202 504-4 V1.1.1:2008 specifies the Short Messaging Web Service for Parlay X 3 in the OSA architecture. It covers the service interface, message structures, notification behavior, faults, service policies, namespaces, and the WSDL representation needed to implement the service.
The document is organized into clauses for scope, references, definitions and abbreviations, detailed service description, namespaces, sequence diagrams, XML Schema data type definition, web service interface definition, fault definitions, and service policies. Annex A gives the normative WSDL for Short Messaging, and Annex B provides an informative bibliography.
| Annex | What it covers |
|---|---|
| Annex A | Normative WSDL for Short Messaging |
| Annex B | Informative bibliography |
What are the key requirements of SIST ES 202 504-4 V1.1.1:2008?
SIST ES 202 504-4 V1.1.1:2008 defines how an application can send, schedule, receive, and monitor SMS through a web service interface. The main practical point is that the document supports both polling and asynchronous notification, so an application can choose the integration style that fits its system design.
Service model and messaging behavior
Clause 4 describes ShortMessaging as a Parlay X 3 Web Service that hides low-level telecom details behind simple operations. It provides primitives for sending SMS, receiving SMS, and monitoring delivery status, which matters because an application can work through the service interface instead of using SMS-specific network protocols.
Clause 4 also describes two ways to track activity: polling and notification. For outgoing messages, the application can call getSmsDeliveryStatus after sendSms, or it can use notifySmsDeliveryReceipt through the notification interface; for incoming messages, it can poll with getReceivedSms or receive asynchronous notification with notifySmsReception.
Namespaces and data typing
Clause 5 assigns distinct namespaces to the SendSms, ReceiveSms, SmsNotification, and SmsNotificationManager interfaces, plus a separate namespace for the SMS data types. This matters in implementation because the WSDL and XML messages must use the right namespace URIs to interoperate correctly.
Clause 7 defines the main data structures and enumerations used by the service. These include DeliveryStatus for delivery results, SmsFormat for message conversion, SmsMessage for received content, and ScheduledDeliveryStatus and ScheduledDeliveryInformation for scheduled sending. In practice, these types tell the application how to represent status, content, and scheduling state in requests and responses.
Sending, scheduling, and tracking SMS
Clause 8.1 defines the SendSms interface for SMS text, logo, and ringtone messages, plus scheduled versions of those operations. The request messages can carry destination addresses, an optional sender name, charging information, and an optional receipt request, which is important because the application must decide whether it wants delivery-receipt callbacks or later polling with a requestIdentifier.
Clause 8.1 also describes how longer text or ringtone content may be split into concatenated short messages. That matters for application logic because a single message can be delivered as multiple SMS parts, and delivery status is only final when the full set of parts reaches the network or terminal.
For logos and ringtones, the interface supports conversion through SmsFormat, with values such as Ems and SmartMessaging. This is relevant when an application sends non-text SMS content and needs the payload converted into a format the terminal can handle.
Scheduled sending uses scheduleSms, scheduleSmsLogo, and scheduleSmsRingtone, with startTime and stopTime in the request. The service also provides cancelScheduledSms and getScheduledSmsStatus, so an application can stop a pending schedule or check whether it was sent, partially sent, cancelled, or unavailable.
Notification, reception, and retention
Clause 8.2 defines the application-side notification interface. notifySmsReception delivers received SMS messages to the application, and notifySmsDeliveryReceipt delivers delivery results for sent messages. Clause 8.4 adds management operations to start and stop these notifications, which matters because the application must configure the service before notifications are delivered.
Clause 8.4.1 uses criteria to filter incoming SMS by the first word of the message, with case-insensitive matching. It also requires unique correlators and unique combinations of service activation number and criteria, so implementers need to plan notification routing carefully to avoid overlap.
Clause 8.3 defines getReceivedSms as a polling mechanism. It returns messages received since the previous call and removes them from the server after retrieval, with a further time limit controlled by a service policy. That means the application must retrieve messages within the allowed retention window.
Faults and service policies
Clause 9 defines the main service exceptions, including message too long, unrecognized data format, delivery receipt notification not supported, duplicate correlator, and overlapping criteria. These faults matter in integration because they tell the application why a request was rejected and what parameter or setup problem needs to be fixed.
Clause 10 lists the service policies that affect behavior at deployment time. GroupSupport, NestedGroupSupport, and ChargingSupported describe platform capabilities, while StatusRetentionTime and MessageRetentionTime control how long delivery status and received messages remain available.
What terms does SIST ES 202 504-4 V1.1.1:2008 define?
- SMS means Short Message Service, the message type handled by the service.
- SMS-C means Short Message Service-Centre, the network element that processes SMS traffic.
- correlator is the identifier used to match a notification or callback with the original request.
- requestIdentifier is the identifier returned for a send or schedule request and later used for polling or cancellation.
- smsServiceActivationNumber is the destination address that activates SMS reception or notification for an application.
- SmsFormat is the enumeration that tells the service how to convert logo or ringtone content before delivery.
- DeliveryStatus is the delivery result enumeration used for sent SMS status reporting.
- Whitespace is treated according to the CFWS definition from RFC 2822.
Who uses SIST ES 202 504-4 V1.1.1:2008?
SIST ES 202 504-4 V1.1.1:2008 is used by application developers who need SMS functions through a web service, and by service providers that expose those functions on their platforms. It is also relevant to architects and integrators building portal services, notification workflows, or messaging gateways that interact with a mobile network or SMS-C.
The document’s examples show a portal sending an SMS on behalf of a user and an application reacting to received SMS messages. That makes it useful for service design, interface implementation, and testing of SMS-based application flows.
Which standards are used with SIST ES 202 504-4 V1.1.1:2008?
- ES 202 504-1 - Provides the common Parlay X 3 definitions used by this part, including shared structures such as SimpleReference and ChargingInformation.
- XML Schema Part 2: Datatypes - Supplies the XML Schema datatypes used in the XML structures and message definitions.
- ETSI TS 123 040 - Provides the SMS realization referenced for the message and format handling, including the EMS context for logo and ringtone formats.
- RFC 2822 - Defines the whitespace-related CFWS concept used in the message criteria matching rules.
What does the SIST ES 202 504-4 V1.1.1:2008 document contain?
The document contains a short service description, namespace declarations, a send-and-status sequence diagram, XML Schema type definitions, WSDL interface definitions, fault definitions, and service policy definitions. It also includes the operation-level messages for sending SMS, sending SMS logos, sending SMS ringtones, scheduling those messages, cancelling schedules, and querying delivery or reception status.
Annex A contains the document/literal WSDL representation used for implementation. The main body also describes the data structures for delivery information, scheduled delivery information, and received SMS messages, which are the core payloads used in testing and integration.
The interface section covers SendSms, SmsNotification, ReceiveSms, and SmsNotificationManager. In practice, these are the pieces a developer maps into client code, server endpoints, and callback handlers.
Buy Documents
ETSI ES 202 504-4 V1.1.1 (2008-02) - Open Service Access (OSA); Parlay X Web Services; Part 4: Short Messaging (Parlay X 3)
ETSI ES 202 504-4 V1.1.1 (2008-05) - Open Service Access (OSA); Parlay X Web Services; Part 4: Short Messaging (Parlay X 3)
Get Certified
Connect with accredited certification bodies for this standard
BSI Group
BSI (British Standards Institution) is the business standards company that helps organizations make excellence a habit.
NYCE
Mexican standards and certification body.
Sponsored listings
Frequently Asked Questions
SIST ES 202 504-4 V1.1.1:2008 is a standard published by the Slovenian Institute for Standardization (SIST). Its full title is "Open Service Access (OSA) - Parlay X Web Services - Part 4: Short Messaging (Parlay X 3)". This standard covers: New edition of ParlayX specification based on requirements in EG 201 988-4, corresponding to 3GPP TS 29.199 Rel-7. The present document is part 4 of the Stage 3 Parlay X 3 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 Short 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.
New edition of ParlayX specification based on requirements in EG 201 988-4, corresponding to 3GPP TS 29.199 Rel-7. The present document is part 4 of the Stage 3 Parlay X 3 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 Short 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.
SIST ES 202 504-4 V1.1.1:2008 is classified under the following ICS (International Classification for Standards) categories: 35.100.01 - Open systems interconnection in general. The ICS classification helps identify the subject area and facilitates finding related standards.
SIST ES 202 504-4 V1.1.1:2008 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
Final draft ETSI ES 202 504-4 V1.1.1 (2008-02)
ETSI Standard
Open Service Access (OSA);
Parlay X Web Services;
Part 4: Short Messaging
(Parlay X 3)
�
2 Final draft ETSI ES 202 504-4 V1.1.1 (2008-02)
Reference
DES/TISPAN-01034-4-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
3 Final draft ETSI ES 202 504-4 V1.1.1 (2008-02)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.7
2 References.7
2.1 Normative references.7
3 Definitions and abbreviations.8
3.1 Definitions.8
3.2 Abbreviations.8
4 Detailed service description .8
5 Namespaces.10
6 Sequence diagrams.10
6.1 Send SMS and report status.10
7 XML Schema data type definition .11
7.1 DeliveryStatus enumeration.11
7.2 SmsFormat enumeration.11
7.3 DeliveryInformation structure.11
7.4 SmsMessage structure.11
7.5 ScheduledDeliveryStatus enumeration.12
7.6 ScheduledDeliveryInformation structure.12
8 Web Service interface definition.12
8.1 Interface: SendSms.12
8.1.1 Operation: sendSms.13
8.1.1.1 Input message: sendSmsRequest.13
8.1.1.2 Output message: sendSmsResponse.13
8.1.1.3 Referenced faults.13
8.1.2 Operation: sendSmsLogo.14
8.1.2.1 Input message: sendSmsLogoRequest .14
8.1.2.2 Output message: sendSmsLogoResponse .14
8.1.2.3 Referenced faults.14
8.1.3 Operation: sendSmsRingtone.14
8.1.3.1 Input message: sendSmsRingtoneRequest .15
8.1.3.2 Output message: sendSmsRingtoneResponse .15
8.1.3.3 Referenced faults.15
8.1.4 Operation: getSmsDeliveryStatus.16
8.1.4.1 Input message: getSmsDeliveryStatusRequest.16
8.1.4.2 Output message: getSmsDeliveryStatusResponse .16
8.1.4.3 Referenced faults.16
8.1.5 Operation: scheduleSms.16
8.1.5.1 Input message: scheduleSmsRequest .17
8.1.5.2 Output message: scheduleSmsResponse.17
8.1.5.3 Referenced faults.17
8.1.6 Operation: scheduleSmsLogo.17
8.1.6.1 Input message: scheduleSmsLogoRequest.18
8.1.6.2 Output message: scheduleSmsLogoResponse.18
8.1.6.3 Referenced faults.18
8.1.7 Operation: scheduleSmsRingtone.18
8.1.7.1 Input message: scheduleSmsRingtoneRequest.19
8.1.7.2 Output message: scheduleSmsRingtoneResponse.19
8.1.7.3 Referenced faults.19
8.1.8 Operation: cancelScheduledSms.19
8.1.8.1 Input message: cancelScheduledSmsRequest.19
ETSI
4 Final draft ETSI ES 202 504-4 V1.1.1 (2008-02)
8.1.8.2 Output message: cancelScheduledSmsResponse .20
8.1.8.3 Referenced faults.20
8.1.9 Operation: getScheduledSmsStatus.20
8.1.9.1 Input message: getScheduledSmsStatusRequest.20
8.1.9.2 Output message: getScheduledSmsStatusResponse.20
8.1.9.3 Referenced faults.20
8.2 Interface: SmsNotification.20
8.2.1 Operation: notifySmsReception.20
8.2.1.1 Input message: notifySmsReceptionRequest .21
8.2.1.2 Output message: notifySmsReceptionResponse .21
8.2.1.3 Referenced faults.21
8.2.2 Operation: notifySmsDeliveryReceipt.21
8.2.2.1 Input message: notifySmsDeliveryReceiptRequest .22
8.2.2.2 Output message: notifySmsDeliveryReceiptResponse.22
8.2.2.3 Referenced faults.22
8.3 Interface: ReceiveSms.22
8.3.1 Operation: getReceivedSms.22
8.3.1.1 Input message: getReceivedSmsRequest .22
8.3.1.2 Output message: getReceivedSmsResponse.22
8.3.1.3 Referenced faults.22
8.4 Interface: SmsNotificationManager.23
8.4.1 Operation: startSmsNotification.23
8.4.1.1 Input message: startSmsNotificationRequest.23
8.4.1.2 Output message: startSmsNotificationResponse.23
8.4.1.3 Referenced faults.23
8.4.2 Operation: stopSmsNotification.24
8.4.2.1 Input message: stopSmsNotificationRequest .24
8.4.2.2 Output message: stopSmsNotificationResponse.24
8.4.2.3 Referenced faults.24
8.4.3 Operation: startDeliveryReceiptNotification .24
8.4.3.1 Input message: startDeliveryReceiptNotificationRequest.24
8.4.3.2 Output message: startDeliveryReceiptNotificationResponse.24
8.4.3.3 Referenced faults.24
8.4.4 Operation: stopDeliveryReceiptNotification .25
8.4.4.1 Input message: stopDeliveryReceiptNotificationRequest .25
8.4.4.2 Output message: stopDeliveryReceiptNotificationResponse.25
8.4.4.3 Referenced faults.25
9 Fault definitions.25
9.1 ServiceException.25
9.1.1 SVC0280: Message too long .25
9.1.2 SVC0281: Unrecognized data format.25
9.1.3 Void.26
9.1.4 SVC0283: Delivery Receipt Notification not supported.26
10 Service policies .26
Annex A (normative): WSDL for Short Messaging.27
Annex B (informative): Bibliography.28
History .29
ETSI
5 Final draft ETSI ES 202 504-4 V1.1.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 4 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";
Part 15: "Message Broadcast";
Part 16: "Geocoding";
Part 17: "Application-driven Quality of Service (QoS)";
Part 18: "Device Capabilities and Configuration";
Part 19: "Multimedia Streaming Control";
Part 20: "Multimedia Multicast Session Management".
ETSI
6 Final draft ETSI ES 202 504-4 V1.1.1 (2008-02)
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 3.0 set of specifications.
The present document is equivalent to 3GPP TS 29.199-04 V7.2.0 (Release 7).
ETSI
7 Final draft ETSI ES 202 504-4 V1.1.1 (2008-02)
1 Scope
The present document is part 4 of the Stage 3 Parlay X 3 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 Short 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
8 Final draft ETSI ES 202 504-4 V1.1.1 (2008-02)
[2] ETSI ES 202 504-1: "Open Service Access (OSA); Parlay X Web Services; Part 1: Common
(Parlay X 3)".
[3] 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)".
[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 504-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 504-1 [2] and the following apply:
SMS Short Message Service
SMS-C Short Message Service-Centre
4 Detailed service description
Currently, in order to programmatically receive and send SMS it is necessary to write applications using specific
protocols to access SMS functions provided by network elements (e.g. SMS-C). This approach requires a high degree of
network expertise. Alternatively it is possible to use the Parlay/OSA approach, invoking standard interfaces (e.g. User
Interaction or Messaging Service Interfaces) to gain access to SMS capabilities, but these interfaces are usually
perceived to be quite complex by IT application developers. Developers must have advanced telecommunication skills
to use OSA interfaces.
In this clause is described a Parlay X 3 Web Service, for sending and receiving SMS messages. The overall scope of
this Web Service is to provide to application developers primitives to handle SMS in a simple way. In fact, using the
SMS Web Service, application developers can invoke SMS functions without specific Telco knowledge.
ShortMessaging provides operations (see clause 8.1, SendSms API) for sending an SMS message to the network and a
polling mechanism for monitoring the delivery status of a sent SMS message. It also provide an asynchronous
notification mechanism for delivery status (see clause 8.2.2, SmsNotification API: notifySmsDeliveryReceipt
operation). In addition, a mechanism is provided to start and stop the notification of delivery receipts (see clause 8.4,
SmsNotificationManager API).
ShortMessaging also allows an application to receive SMS messages. Both a polling (see clause 8.3, ReceiveSms API)
and an asynchronous notification mechanism (see clause 8.2.1, SmsNotification API: notifySmsReception operation
and clause 8.4, SmsNotificationManager API) are available.
Figure 1 shows a scenario using the SMS Web Service to send an SMS message from an application. The application
invokes a Web Service to retrieve a weather forecast for a subscriber (1) and (2) and a Parlay X 3 Interface (3) to use
the SMS Web Service operations (i.e. to send an SMS). After invocation, the SMS Web Service invokes a Parlay API
method (4) using the Parlay/OSA SCS (Generic User Interaction) interface. This SCS handles the invocation and sends
an UCP operation (5) to an SMS-C. Subsequently the weather forecast is delivered (6) to the subscriber.
In an alternative scenario, the Parlay API interaction involving steps (4) and (5) could be replaced with a direct
interaction between the SMS Web Service and the Mobile network.
ETSI
9 Final draft ETSI ES 202 504-4 V1.1.1 (2008-02)
SMS Web
Weather Info
Info meteo SMS-X
Service
Web Service
Web Service component
Parlay X I/F
SCS-SMS
SCS-SMS
1 Parlay API
Parlay Gateway
…….
You have
getMeteoInfo()
a new SMS…
….
…Weather info
SMS-C
Retrieve
SMS-C
user Profile
….
Mobile network
SendSms (
“Weather inf.o.”,,,)
User
profile
Figure 1: Send SMS Scenario
Figure 2 shows a scenario using the SMS Web Service to deliver a received SMS message to an application. The
application receives a Parlay X 3 Web Service invocation for an SMS sent by a subscriber (1) and (2). The SMS
message contains the e-mail address of the person the user wishes to call. The application invokes a Parlay X Interface
(3) to the Third Party Call Web Service in order to initiate the call (4).
Third Party Call
3PC-X
Web Service
component
Mobile network
Parlay X I/F
SMS Web 1
SMS-X
Service
3 component
Parlay X I/F
SOAP
SOAP
Call
mary@company.com
…….
notifySmsReception()
{….
Retrieve
user number
….
makeACall(“.”,,,)
User
profile }
Figure 2: Receive SMS Scenario
ETSI
10 Final draft ETSI ES 202 504-4 V1.1.1 (2008-02)
5 Namespaces
The SendSms interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/sms/send/v3_1
The ReceiveSms interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/sms/receive/v3_1
The SmsNotification interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/sms/notification/v3_1
The SmsNotificationManager interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/sms/notification_manager/v3_2
The data types are defined in the namespace:
http://www.csapi.org/schema/parlayx/sms/v3_0
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 SMS and report status
Sending SMS message from Web portals is a common capability offered by Service Providers. This sequence diagram
shows a portal providing this service.
: End User : Self Serve : Send Sms
Portal Web Service
Enter message text and address
Send SMS message
Message identifier
Short delay
Get message status
Message status
Display result page
Figure 3
ETSI
11 Final draft ETSI ES 202 504-4 V1.1.1 (2008-02)
7 XML Schema data type definition
7.1 DeliveryStatus enumeration
List of delivery status values.
Enumeration value Description
DeliveredToNetwork Successful delivery to 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 delivered to Terminal.
DeliveryNotificationNotS Unable to provide delivery receipt notification. The notifySMSDeliveryReceipt
upported operation will return "DeliveryNotificationNotSupported" to indicate that delivery
receipt for the specified address in a sendSMS…Request message is not
supported.
7.2 SmsFormat enumeration
List of SMS format values.
Enumeration value Description
Ems Enhanced Messaging Service, standardized in TS 123 040 [3], which defines a
logo/ringtone format
TM
Defines a logo/ringtone format
SmartMessaging
7.3 DeliveryInformation structure
Delivery status information.
Element name Element type Optional Description
address xsd:anyURI No It indicates the destination address to which the notification is related
deliveryStatus DeliveryStatus No Indicates the delivery result for the destination address
7.4 SmsMessage structure
SMS message information. The senderAddress is the address from which the message was actually sent, which may or
may not match the senderName value provided in the sendSms operation.
Element name Element type Optional Description
message xsd:string No Text received in SMS
senderAddress xsd:anyURI No It indicates address sending the SMS
smsServiceActivation xsd:anyURI No Number associated with the invoked Message service, i.e. the
Number destination address used to send the message
dateTime xsd:dateTime Yes Time when message was received by operator
ETSI
12 Final draft ETSI ES 202 504-4 V1.1.1 (2008-02)
7.5 ScheduledDeliveryStatus enumeration
List of scheduled SMS delivery status values.
Enumeration value Description
Scheduled The Message has been scheduled, the scheduled time has not started.
NotSent Message could not be sent before end of scheduled time.
Sent The Message has been sent within the scheduled time.
Cancelled Message has been cancelled. Some messages may have been sent.
PartiallySent Message is sent to some, but not to all the recipients.
StatusUnavailable Unable to provide delivery information.
7.6 ScheduledDeliveryInformation structure
Scheduled delivery information.
Element name Element type Optional Description
deliveryStatus
...
ETSI Standard
Open Service Access (OSA);
Parlay X Web Services;
Part 4: Short Messaging
(Parlay X 3)
�
2 ETSI ES 202 504-4 V1.1.1 (2008-05)
Reference
DES/TISPAN-01034-4-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
3 ETSI ES 202 504-4 V1.1.1 (2008-05)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.7
2 References.7
2.1 Normative references.7
3 Definitions and abbreviations.8
3.1 Definitions.8
3.2 Abbreviations.8
4 Detailed service description .8
5 Namespaces.10
6 Sequence diagrams.10
6.1 Send SMS and report status.10
7 XML Schema data type definition .11
7.1 DeliveryStatus enumeration.11
7.2 SmsFormat enumeration.11
7.3 DeliveryInformation structure.11
7.4 SmsMessage structure.11
7.5 ScheduledDeliveryStatus enumeration.12
7.6 ScheduledDeliveryInformation structure.12
8 Web Service interface definition.12
8.1 Interface: SendSms.12
8.1.1 Operation: sendSms.13
8.1.1.1 Input message: sendSmsRequest.13
8.1.1.2 Output message: sendSmsResponse.13
8.1.1.3 Referenced faults.13
8.1.2 Operation: sendSmsLogo.14
8.1.2.1 Input message: sendSmsLogoRequest .14
8.1.2.2 Output message: sendSmsLogoResponse .14
8.1.2.3 Referenced faults.14
8.1.3 Operation: sendSmsRingtone.14
8.1.3.1 Input message: sendSmsRingtoneRequest .15
8.1.3.2 Output message: sendSmsRingtoneResponse .15
8.1.3.3 Referenced faults.15
8.1.4 Operation: getSmsDeliveryStatus.16
8.1.4.1 Input message: getSmsDeliveryStatusRequest.16
8.1.4.2 Output message: getSmsDeliveryStatusResponse .16
8.1.4.3 Referenced faults.16
8.1.5 Operation: scheduleSms.16
8.1.5.1 Input message: scheduleSmsRequest .17
8.1.5.2 Output message: scheduleSmsResponse.17
8.1.5.3 Referenced faults.17
8.1.6 Operation: scheduleSmsLogo.17
8.1.6.1 Input message: scheduleSmsLogoRequest.18
8.1.6.2 Output message: scheduleSmsLogoResponse.18
8.1.6.3 Referenced faults.18
8.1.7 Operation: scheduleSmsRingtone.18
8.1.7.1 Input message: scheduleSmsRingtoneRequest.19
8.1.7.2 Output message: scheduleSmsRingtoneResponse.19
8.1.7.3 Referenced faults.19
8.1.8 Operation: cancelScheduledSms.19
8.1.8.1 Input message: cancelScheduledSmsRequest.19
ETSI
4 ETSI ES 202 504-4 V1.1.1 (2008-05)
8.1.8.2 Output message: cancelScheduledSmsResponse .20
8.1.8.3 Referenced faults.20
8.1.9 Operation: getScheduledSmsStatus.20
8.1.9.1 Input message: getScheduledSmsStatusRequest.20
8.1.9.2 Output message: getScheduledSmsStatusResponse.20
8.1.9.3 Referenced faults.20
8.2 Interface: SmsNotification.20
8.2.1 Operation: notifySmsReception.20
8.2.1.1 Input message: notifySmsReceptionRequest .21
8.2.1.2 Output message: notifySmsReceptionResponse .21
8.2.1.3 Referenced faults.21
8.2.2 Operation: notifySmsDeliveryReceipt.21
8.2.2.1 Input message: notifySmsDeliveryReceiptRequest .22
8.2.2.2 Output message: notifySmsDeliveryReceiptResponse.22
8.2.2.3 Referenced faults.22
8.3 Interface: ReceiveSms.22
8.3.1 Operation: getReceivedSms.22
8.3.1.1 Input message: getReceivedSmsRequest .22
8.3.1.2 Output message: getReceivedSmsResponse.22
8.3.1.3 Referenced faults.22
8.4 Interface: SmsNotificationManager.23
8.4.1 Operation: startSmsNotification.23
8.4.1.1 Input message: startSmsNotificationRequest.23
8.4.1.2 Output message: startSmsNotificationResponse.23
8.4.1.3 Referenced faults.23
8.4.2 Operation: stopSmsNotification.24
8.4.2.1 Input message: stopSmsNotificationRequest .24
8.4.2.2 Output message: stopSmsNotificationResponse.24
8.4.2.3 Referenced faults.24
8.4.3 Operation: startDeliveryReceiptNotification .24
8.4.3.1 Input message: startDeliveryReceiptNotificationRequest.24
8.4.3.2 Output message: startDeliveryReceiptNotificationResponse.24
8.4.3.3 Referenced faults.24
8.4.4 Operation: stopDeliveryReceiptNotification .25
8.4.4.1 Input message: stopDeliveryReceiptNotificationRequest .25
8.4.4.2 Output message: stopDeliveryReceiptNotificationResponse.25
8.4.4.3 Referenced faults.25
9 Fault definitions.25
9.1 ServiceException.25
9.1.1 SVC0280: Message too long .25
9.1.2 SVC0281: Unrecognized data format.25
9.1.3 Void.26
9.1.4 SVC0283: Delivery Receipt Notification not supported.26
10 Service policies .26
Annex A (normative): WSDL for Short Messaging.27
Annex B (informative): Bibliography.28
History .29
ETSI
5 ETSI ES 202 504-4 V1.1.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 4 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";
Part 15: "Message Broadcast";
Part 16: "Geocoding";
Part 17: "Application-driven Quality of Service (QoS)";
Part 18: "Device Capabilities and Configuration";
Part 19: "Multimedia Streaming Control";
Part 20: "Multimedia Multicast Session Management".
ETSI
6 ETSI ES 202 504-4 V1.1.1 (2008-05)
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 3.0 set of specifications.
The present document is equivalent to 3GPP TS 29.199-04 V7.2.0 (Release 7).
ETSI
7 ETSI ES 202 504-4 V1.1.1 (2008-05)
1 Scope
The present document is part 4 of the Stage 3 Parlay X 3 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 Short 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
8 ETSI ES 202 504-4 V1.1.1 (2008-05)
[2] ETSI ES 202 504-1: "Open Service Access (OSA); Parlay X Web Services; Part 1: Common
(Parlay X 3)".
[3] 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)".
[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 504-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 504-1 [2] and the following apply:
SMS Short Message Service
SMS-C Short Message Service-Centre
4 Detailed service description
Currently, in order to programmatically receive and send SMS it is necessary to write applications using specific
protocols to access SMS functions provided by network elements (e.g. SMS-C). This approach requires a high degree of
network expertise. Alternatively it is possible to use the Parlay/OSA approach, invoking standard interfaces (e.g. User
Interaction or Messaging Service Interfaces) to gain access to SMS capabilities, but these interfaces are usually
perceived to be quite complex by IT application developers. Developers must have advanced telecommunication skills
to use OSA interfaces.
In this clause is described a Parlay X 3 Web Service, for sending and receiving SMS messages. The overall scope of
this Web Service is to provide to application developers primitives to handle SMS in a simple way. In fact, using the
SMS Web Service, application developers can invoke SMS functions without specific Telco knowledge.
ShortMessaging provides operations (see clause 8.1, SendSms API) for sending an SMS message to the network and a
polling mechanism for monitoring the delivery status of a sent SMS message. It also provide an asynchronous
notification mechanism for delivery status (see clause 8.2.2, SmsNotification API: notifySmsDeliveryReceipt
operation). In addition, a mechanism is provided to start and stop the notification of delivery receipts (see clause 8.4,
SmsNotificationManager API).
ShortMessaging also allows an application to receive SMS messages. Both a polling (see clause 8.3, ReceiveSms API)
and an asynchronous notification mechanism (see clause 8.2.1, SmsNotification API: notifySmsReception operation
and clause 8.4, SmsNotificationManager API) are available.
Figure 1 shows a scenario using the SMS Web Service to send an SMS message from an application. The application
invokes a Web Service to retrieve a weather forecast for a subscriber (1) and (2) and a Parlay X 3 Interface (3) to use
the SMS Web Service operations (i.e. to send an SMS). After invocation, the SMS Web Service invokes a Parlay API
method (4) using the Parlay/OSA SCS (Generic User Interaction) interface. This SCS handles the invocation and sends
an UCP operation (5) to an SMS-C. Subsequently the weather forecast is delivered (6) to the subscriber.
In an alternative scenario, the Parlay API interaction involving steps (4) and (5) could be replaced with a direct
interaction between the SMS Web Service and the Mobile network.
ETSI
9 ETSI ES 202 504-4 V1.1.1 (2008-05)
SMS Web
Weather Info
Info meteo SMS-X
Service
Web Service
Web Service component
Parlay X I/F
SCS-SMS
SCS-SMS
1 Parlay API
Parlay Gateway
…….
You have
getMeteoInfo()
a new SMS…
….
…Weather info
SMS-C
Retrieve
SMS-C
user Profile
….
Mobile network
SendSms (
“Weather inf.o.”,,,)
User
profile
Figure 1: Send SMS Scenario
Figure 2 shows a scenario using the SMS Web Service to deliver a received SMS message to an application. The
application receives a Parlay X 3 Web Service invocation for an SMS sent by a subscriber (1) and (2). The SMS
message contains the e-mail address of the person the user wishes to call. The application invokes a Parlay X Interface
(3) to the Third Party Call Web Service in order to initiate the call (4).
Third Party Call
3PC-X
Web Service
component
Mobile network
Parlay X I/F
SMS Web 1
SMS-X
Service
3 component
Parlay X I/F
SOAP
SOAP
Call
mary@company.com
…….
notifySmsReception()
{….
Retrieve
user number
….
makeACall(“.”,,,)
User
profile }
Figure 2: Receive SMS Scenario
ETSI
10 ETSI ES 202 504-4 V1.1.1 (2008-05)
5 Namespaces
The SendSms interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/sms/send/v3_1
The ReceiveSms interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/sms/receive/v3_1
The SmsNotification interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/sms/notification/v3_1
The SmsNotificationManager interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/sms/notification_manager/v3_2
The data types are defined in the namespace:
http://www.csapi.org/schema/parlayx/sms/v3_0
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 SMS and report status
Sending SMS message from Web portals is a common capability offered by Service Providers. This sequence diagram
shows a portal providing this service.
: End User : Self Serve : Send Sms
Portal Web Service
Enter message text and address
Send SMS message
Message identifier
Short delay
Get message status
Message status
Display result page
Figure 3
ETSI
11 ETSI ES 202 504-4 V1.1.1 (2008-05)
7 XML Schema data type definition
7.1 DeliveryStatus enumeration
List of delivery status values.
Enumeration value Description
DeliveredToNetwork Successful delivery to 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 delivered to Terminal.
DeliveryNotificationNotS Unable to provide delivery receipt notification. The notifySMSDeliveryReceipt
upported operation will return "DeliveryNotificationNotSupported" to indicate that delivery
receipt for the specified address in a sendSMS…Request message is not
supported.
7.2 SmsFormat enumeration
List of SMS format values.
Enumeration value Description
Ems Enhanced Messaging Service, standardized in TS 123 040 [3], which defines a
logo/ringtone format
TM
Defines a logo/ringtone format
SmartMessaging
7.3 DeliveryInformation structure
Delivery status information.
Element name Element type Optional Description
address xsd:anyURI No It indicates the destination address to which the notification is related
deliveryStatus DeliveryStatus No Indicates the delivery result for the destination address
7.4 SmsMessage structure
SMS message information. The senderAddress is the address from which the message was actually sent, which may or
may not match the senderName value provided in the sendSms operation.
Element name Element type Optional Description
message xsd:string No Text received in SMS
senderAddress xsd:anyURI No It indicates address sending the SMS
smsServiceActivation xsd:anyURI No Number associated with the invoked Message service, i.e. the
Number destination address used to send the message
dateTime xsd:dateTime Yes Time when message was received by operator
ETSI
12 ETSI ES 202 504-4 V1.1.1 (2008-05)
7.5 ScheduledDeliveryStatus enumeration
List of scheduled SMS delivery status values.
Enumeration value Description
Scheduled The Message has been scheduled, the scheduled time has not started.
NotSent Message could not be sent before end of scheduled time.
Sent The Message has been sent within the scheduled time.
Cancelled Message has been cancelled. Some messages may have been sent.
PartiallySent Message is sent to some, but not to all the recipients.
StatusUnavailable Unable to provide delivery information.
7.6 ScheduledDeliveryInformation structure
Scheduled delivery information.
Element name Element type Optional Description
deliveryStatus ScheduledDeliveryStat
...
SLOVENSKI STANDARD
01-september-2008
2GSUWLGRVWRSGRVWRULWYH 26$ 6SOHWQHVWRULWYH3DUOD\;GHO .UDWNR
VSRURþDQMH 3DUOD\;
Open Service Access (OSA) - Parlay X Web Services - Part 4: Short Messaging (Parlay
X 3)
Ta slovenski standard je istoveten z: ES 202 504-4 Version 1.1.1
ICS:
35.100.01 Medsebojno povezovanje Open systems
odprtih sistemov na splošno interconnection in general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
ETSI Standard
Open Service Access (OSA);
Parlay X Web Services;
Part 4: Short Messaging
(Parlay X 3)
�
2 ETSI ES 202 504-4 V1.1.1 (2008-05)
Reference
DES/TISPAN-01034-4-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
3 ETSI ES 202 504-4 V1.1.1 (2008-05)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.7
2 References.7
2.1 Normative references.7
3 Definitions and abbreviations.8
3.1 Definitions.8
3.2 Abbreviations.8
4 Detailed service description .8
5 Namespaces.10
6 Sequence diagrams.10
6.1 Send SMS and report status.10
7 XML Schema data type definition .11
7.1 DeliveryStatus enumeration.11
7.2 SmsFormat enumeration.11
7.3 DeliveryInformation structure.11
7.4 SmsMessage structure.11
7.5 ScheduledDeliveryStatus enumeration.12
7.6 ScheduledDeliveryInformation structure.12
8 Web Service interface definition.12
8.1 Interface: SendSms.12
8.1.1 Operation: sendSms.13
8.1.1.1 Input message: sendSmsRequest.13
8.1.1.2 Output message: sendSmsResponse.13
8.1.1.3 Referenced faults.13
8.1.2 Operation: sendSmsLogo.14
8.1.2.1 Input message: sendSmsLogoRequest .14
8.1.2.2 Output message: sendSmsLogoResponse .14
8.1.2.3 Referenced faults.14
8.1.3 Operation: sendSmsRingtone.14
8.1.3.1 Input message: sendSmsRingtoneRequest .15
8.1.3.2 Output message: sendSmsRingtoneResponse .15
8.1.3.3 Referenced faults.15
8.1.4 Operation: getSmsDeliveryStatus.16
8.1.4.1 Input message: getSmsDeliveryStatusRequest.16
8.1.4.2 Output message: getSmsDeliveryStatusResponse .16
8.1.4.3 Referenced faults.16
8.1.5 Operation: scheduleSms.16
8.1.5.1 Input message: scheduleSmsRequest .17
8.1.5.2 Output message: scheduleSmsResponse.17
8.1.5.3 Referenced faults.17
8.1.6 Operation: scheduleSmsLogo.17
8.1.6.1 Input message: scheduleSmsLogoRequest.18
8.1.6.2 Output message: scheduleSmsLogoResponse.18
8.1.6.3 Referenced faults.18
8.1.7 Operation: scheduleSmsRingtone.18
8.1.7.1 Input message: scheduleSmsRingtoneRequest.19
8.1.7.2 Output message: scheduleSmsRingtoneResponse.19
8.1.7.3 Referenced faults.19
8.1.8 Operation: cancelScheduledSms.19
8.1.8.1 Input message: cancelScheduledSmsRequest.19
ETSI
4 ETSI ES 202 504-4 V1.1.1 (2008-05)
8.1.8.2 Output message: cancelScheduledSmsResponse .20
8.1.8.3 Referenced faults.20
8.1.9 Operation: getScheduledSmsStatus.20
8.1.9.1 Input message: getScheduledSmsStatusRequest.20
8.1.9.2 Output message: getScheduledSmsStatusResponse.20
8.1.9.3 Referenced faults.20
8.2 Interface: SmsNotification.20
8.2.1 Operation: notifySmsReception.20
8.2.1.1 Input message: notifySmsReceptionRequest .21
8.2.1.2 Output message: notifySmsReceptionResponse .21
8.2.1.3 Referenced faults.21
8.2.2 Operation: notifySmsDeliveryReceipt.21
8.2.2.1 Input message: notifySmsDeliveryReceiptRequest .22
8.2.2.2 Output message: notifySmsDeliveryReceiptResponse.22
8.2.2.3 Referenced faults.22
8.3 Interface: ReceiveSms.22
8.3.1 Operation: getReceivedSms.22
8.3.1.1 Input message: getReceivedSmsRequest .22
8.3.1.2 Output message: getReceivedSmsResponse.22
8.3.1.3 Referenced faults.22
8.4 Interface: SmsNotificationManager.23
8.4.1 Operation: startSmsNotification.23
8.4.1.1 Input message: startSmsNotificationRequest.23
8.4.1.2 Output message: startSmsNotificationResponse.23
8.4.1.3 Referenced faults.23
8.4.2 Operation: stopSmsNotification.24
8.4.2.1 Input message: stopSmsNotificationRequest .24
8.4.2.2 Output message: stopSmsNotificationResponse.24
8.4.2.3 Referenced faults.24
8.4.3 Operation: startDeliveryReceiptNotification .24
8.4.3.1 Input message: startDeliveryReceiptNotificationRequest.24
8.4.3.2 Output message: startDeliveryReceiptNotificationResponse.24
8.4.3.3 Referenced faults.24
8.4.4 Operation: stopDeliveryReceiptNotification .25
8.4.4.1 Input message: stopDeliveryReceiptNotificationRequest .25
8.4.4.2 Output message: stopDeliveryReceiptNotificationResponse.25
8.4.4.3 Referenced faults.25
9 Fault definitions.25
9.1 ServiceException.25
9.1.1 SVC0280: Message too long .25
9.1.2 SVC0281: Unrecognized data format.25
9.1.3 Void.26
9.1.4 SVC0283: Delivery Receipt Notification not supported.26
10 Service policies .26
Annex A (normative): WSDL for Short Messaging.27
Annex B (informative): Bibliography.28
History .29
ETSI
5 ETSI ES 202 504-4 V1.1.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 4 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";
Part 15: "Message Broadcast";
Part 16: "Geocoding";
Part 17: "Application-driven Quality of Service (QoS)";
Part 18: "Device Capabilities and Configuration";
Part 19: "Multimedia Streaming Control";
Part 20: "Multimedia Multicast Session Management".
ETSI
6 ETSI ES 202 504-4 V1.1.1 (2008-05)
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 3.0 set of specifications.
The present document is equivalent to 3GPP TS 29.199-04 V7.2.0 (Release 7).
ETSI
7 ETSI ES 202 504-4 V1.1.1 (2008-05)
1 Scope
The present document is part 4 of the Stage 3 Parlay X 3 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 Short 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
8 ETSI ES 202 504-4 V1.1.1 (2008-05)
[2] ETSI ES 202 504-1: "Open Service Access (OSA); Parlay X Web Services; Part 1: Common
(Parlay X 3)".
[3] 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)".
[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 504-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 504-1 [2] and the following apply:
SMS Short Message Service
SMS-C Short Message Service-Centre
4 Detailed service description
Currently, in order to programmatically receive and send SMS it is necessary to write applications using specific
protocols to access SMS functions provided by network elements (e.g. SMS-C). This approach requires a high degree of
network expertise. Alternatively it is possible to use the Parlay/OSA approach, invoking standard interfaces (e.g. User
Interaction or Messaging Service Interfaces) to gain access to SMS capabilities, but these interfaces are usually
perceived to be quite complex by IT application developers. Developers must have advanced telecommunication skills
to use OSA interfaces.
In this clause is described a Parlay X 3 Web Service, for sending and receiving SMS messages. The overall scope of
this Web Service is to provide to application developers primitives to handle SMS in a simple way. In fact, using the
SMS Web Service, application developers can invoke SMS functions without specific Telco knowledge.
ShortMessaging provides operations (see clause 8.1, SendSms API) for sending an SMS message to the network and a
polling mechanism for monitoring the delivery status of a sent SMS message. It also provide an asynchronous
notification mechanism for delivery status (see clause 8.2.2, SmsNotification API: notifySmsDeliveryReceipt
operation). In addition, a mechanism is provided to start and stop the notification of delivery receipts (see clause 8.4,
SmsNotificationManager API).
ShortMessaging also allows an application to receive SMS messages. Both a polling (see clause 8.3, ReceiveSms API)
and an asynchronous notification mechanism (see clause 8.2.1, SmsNotification API: notifySmsReception operation
and clause 8.4, SmsNotificationManager API) are available.
Figure 1 shows a scenario using the SMS Web Service to send an SMS message from an application. The application
invokes a Web Service to retrieve a weather forecast for a subscriber (1) and (2) and a Parlay X 3 Interface (3) to use
the SMS Web Service operations (i.e. to send an SMS). After invocation, the SMS Web Service invokes a Parlay API
method (4) using the Parlay/OSA SCS (Generic User Interaction) interface. This SCS handles the invocation and sends
an UCP operation (5) to an SMS-C. Subsequently the weather forecast is delivered (6) to the subscriber.
In an alternative scenario, the Parlay API interaction involving steps (4) and (5) could be replaced with a direct
interaction between the SMS Web Service and the Mobile network.
ETSI
9 ETSI ES 202 504-4 V1.1.1 (2008-05)
SMS Web
Weather Info
Info meteo SMS-X
Service
Web Service
Web Service component
Parlay X I/F
SCS-SMS
SCS-SMS
1 Parlay API
Parlay Gateway
…….
You have
getMeteoInfo()
a new SMS…
….
…Weather info
SMS-C
Retrieve
SMS-C
user Profile
….
Mobile network
SendSms (
“Weather inf.o.”,,,)
User
profile
Figure 1: Send SMS Scenario
Figure 2 shows a scenario using the SMS Web Service to deliver a received SMS message to an application. The
application receives a Parlay X 3 Web Service invocation for an SMS sent by a subscriber (1) and (2). The SMS
message contains the e-mail address of the person the user wishes to call. The application invokes a Parlay X Interface
(3) to the Third Party Call Web Service in order to initiate the call (4).
Third Party Call
3PC-X
Web Service
component
Mobile network
Parlay X I/F
SMS Web 1
SMS-X
Service
3 component
Parlay X I/F
SOAP
SOAP
Call
mary@company.com
…….
notifySmsReception()
{….
Retrieve
user number
….
makeACall(“.”,,,)
User
profile }
Figure 2: Receive SMS Scenario
ETSI
10 ETSI ES 202 504-4 V1.1.1 (2008-05)
5 Namespaces
The SendSms interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/sms/send/v3_1
The ReceiveSms interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/sms/receive/v3_1
The SmsNotification interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/sms/notification/v3_1
The SmsNotificationManager interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/sms/notification_manager/v3_2
The data types are defined in the namespace:
http://www.csapi.org/schema/parlayx/sms/v3_0
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 SMS and report status
Sending SMS message from Web portals is a common capability offered by Service Providers. This sequence diagram
shows a portal providing this service.
: End User : Self Serve : Send Sms
Portal Web Service
Enter message text and address
Send SMS message
Message identifier
Short delay
Get message status
Message status
Display result page
Figure 3
ETSI
11 ETSI ES 202 504-4 V1.1.1 (2008-05)
7 XML Schema data type definition
7.1 DeliveryStatus enumeration
List of delivery status values.
Enumeration value Description
DeliveredToNetwork Successful delivery to 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 delivered to Terminal.
DeliveryNotificationNotS Unable to provide delivery receipt notification. The notifySMSDeliveryReceipt
upported operation will return "DeliveryNotificationNotSupported" to indicate that delivery
receipt for the specified address in a sendSMS…Request message is not
supported.
7.2 SmsFormat enumeration
List of SMS format values.
Enumeration value Description
Ems Enhanced Messaging Service, standardized in TS 123 040 [3], which defines a
logo/ringtone format
TM
Defines a logo/ringtone format
SmartMessaging
7.3 DeliveryInformation structure
Delivery status information.
Element name Element type Optional Description
address xsd:anyURI No It indicates the destination address to which the notification is related
deliveryStatus DeliveryStatus No Indicates the delivery result for the destination address
7.4 SmsMessage structure
SMS message information. The senderAddress is the address from which the message was actually sent, which may or
may not match the senderName value provided in the sendSms operation.
Element name Element type Optional Description
message xsd:string No Text received in SMS
senderAddress xsd:anyURI No It indicates address sending the SMS
smsServiceActivation xsd:anyURI No Number associated with the invoked Message service, i.e. the
Number destination address used to send the message
dateTime xsd:dateTime Yes Time when message was received by operator
ETSI
12 ETSI ES 202 504-4 V1.1.1 (2008-05)
7.5 ScheduledDeliveryStatus enumeration
List of scheduled SMS delivery status values.
Enumeration value Description
Scheduled The Message has been scheduled, the scheduled time has not started.
NotSent Message could not be sent before end of scheduled time.
Sent The Message has been sent within the scheduled time.
Cancelled Message has been cancelled. Some messages may have been sent.
PartiallySent Messag
...