2
Copyright and Legal Notice Copyright © 2011-2013 Dialogic Inc. All Rights Reserved. You may not reproduce this document in whole or in part without permission
in writing from Dialogic Inc. at the address provided below.
All contents of this document are furnished for informational use only and are subject to change without notice and do not represent a
commitment on the part of Dialogic Inc. and its affiliates or subsidiaries (“Dialogic”). Reasonable effort is made to ensure the accuracy
of the information contained in the document. However, Dialogic does not warrant the accuracy of this information and cannot accept
responsibility for errors, inaccuracies or omissions that may be contained in this document.
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH DIALOGIC® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN
A SIGNED AGREEMENT BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS
ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY OR
WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY INTELLECTUAL
PROPERTY RIGHT OF A THIRD PARTY.
Dialogic products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility
applications.
Due to differing national regulations and approval requirements, certain Dialogic products may be suitable for use only in specific countries, and thus may not function properly in other countries. You are responsible for ensuring that your use of such products occurs
only in the countries where such use is suitable. For information on specific products, contact Dialogic Inc. at the address indicated
below or on the web at www.dialogic.com.
It is possible that the use or implementation of any one of the concepts, applications, or ideas described in this document, in marketing
collateral produced by or on web pages maintained by Dialogic may infringe one or more patents or other intellectual property rights
owned by third parties. Dialogic does not provide any intellectual property licenses with the sale of Dialogic products other than a
license to use such product in accordance with intellectual property owned or validly licensed by Dialogic and no such licenses are
provided except pursuant to a signed agreement with Dialogic. More detailed information about such intellectual property is available from Dialogic’s legal department at 926 Rock Avenue, San Jose, California 95131 USA. Dialogic encourages all users of its
products to procure all necessary intellectual property licenses required to implement any concepts or applications and
does not condone or encourage any intellectual property infringement and disclaims any responsibility related thereto.
These intellectual property licenses may differ from country to country and it is the responsibility of those who develop
the concepts or applications to be aware of and comply with different national license requirements.
Dialogic, Dialogic Pro, Dialogic Blue, Veraz, Brooktrout, Diva, Diva ISDN, Making Innovation Thrive, Video is the New Voice, Diastar,
Cantata, TruFax, SwitchKit, SnowShore, Eicon, Eicon Networks, NMS Communications, NMS (stylized), Eiconcard, SIPcontrol,
TrustedVideo, Exnet, EXS, Connecting to Growth, Fusion, Vision, PowerMedia, PacketMedia, BorderNet, inCloud9, I-Gate, Hi-Gate,
NaturalAccess, NaturalCallControl, NaturalConference, NaturalFax and Shiva, among others as well as related logos, are either registered trademarks or trademarks of Dialogic Inc. and its affiliates or subsidiaries. Dialogic's trademarks may be used publicly only
with permission from Dialogic. Such permission may only be granted by Dialogic’s legal department at 926 Rock Avenue, San Jose,
California 95131 USA. Any authorized use of Dialogic's trademarks will be subject to full respect of the trademark guidelines published
by Dialogic from time to time and any use of Dialogic’s trademarks requires proper acknowledgement.
The names of actual companies and products mentioned herein are the trademarks of their respective owners.
This document discusses one or more open source products, systems and/or releases. Dialogic is not responsible for your decision to
use open source in connection with Dialogic products (including without limitation those referred to herein), nor is Dialogic responsible for any present or future effects such usage might have, including without limitation effects on your products, your business, or your
intellectual property rights.
Publication Date: February 2013
Document Number: U01LGD
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
3
Revision History
Issue Date Description
4 February 2013 Addition of multiple profiles
3 April 2012 Support for SWS Release 1.1.0 added.
2 September 2011 General Availability
1 July 2011 Initial version for Beta release
Contents
Revision History ........................................................................................................... 3
Contents ....................................................................................................................... 3
1 Introduction ........................................................................................................ 7
1.1 Signaling Service Support ........................................................................................................ 7 1.2 Feature Overview .................................................................................................................... 7 1.3 Abbreviations ......................................................................................................................... 7 1.4 Related Information ................................................................................................................ 8
2 SWS Mode Overview ............................................................................................ 9
2.1 Architecture Overview ............................................................................................................. 9 2.1.1 Signaling Topologies ................................................................................................. 10
2.2 Multiple Network Support ....................................................................................................... 13 2.2.1 Protocol Handling for Multiple Network Contexts ........................................................... 13 2.2.2 Inter-SWS Communications ....................................................................................... 15 2.2.3 Transaction-Based Applications .................................................................................. 15 2.2.4 Management of Local SCCP Sub-Systems .................................................................... 15 2.2.5 Alarms .................................................................................................................... 16
2.3 Interfaces ............................................................................................................................ 16 2.3.1 Application Interface ................................................................................................. 17 2.3.2 Configuration Interface .............................................................................................. 17 2.3.3 Management Interface, Trace, and Diagnostics ............................................................. 18 2.3.4 Network Interfaces ................................................................................................... 18
3 Web Services APIs ............................................................................................ 19
3.1 Overview ............................................................................................................................. 19 3.2 Summary ............................................................................................................................. 20
3.2.1 Supported URIs / Methods ......................................................................................... 20 3.2.2 Payload Structure ..................................................................................................... 21 3.2.3 HTTP Response Codes ............................................................................................... 21
3.3 MAP Services Used ................................................................................................................ 22
4 Short Message API ............................................................................................ 23
4.1 Sending an SMS ................................................................................................................... 23 4.1.1 Support for Report SM Delivery .................................................................................. 25
4.2 Receiving an SMS ................................................................................................................. 26 4.3 Sending a binary format SMS ................................................................................................. 27 4.4 Receiving a binary format SMS ............................................................................................... 28 4.5 Sending a concatenated binary format SMS.............................................................................. 29 4.6 Receiving a concatenated binary format SMS ........................................................................... 30 4.7 Mobile Originated SMS ........................................................................................................... 31
Contents
4
4.8 Sending Atomic MT-SMS ........................................................................................................ 32 4.9 Sending a binary format Atomic MT-SMS ................................................................................. 34 4.10 Sending Concatenated Atomic MT-SMS .................................................................................... 35 4.11 Sending Atomic Send Routing Info For SM ............................................................................... 36 4.12 Sending Atomic Report SM Delivery ........................................................................................ 37 4.13 Sending Atomic Ready For SM ................................................................................................ 38 4.14 Receiving Atomic Send Routing Info For SM ............................................................................. 39 4.15 Receiving an Alert Service Centre ........................................................................................... 41
5 USSD API ........................................................................................................... 44
5.1 Mobile Initiated Sessions ....................................................................................................... 44 5.2 Client Application Initiated Session ......................................................................................... 46 5.3 Client Application Initiated - USSD Notify ................................................................................. 47
6 Location and Subscriber Polling API .................................................................. 49
6.1 Location API ......................................................................................................................... 49 6.2 Subscriber State API ............................................................................................................. 50 6.3 Get IMSI API ........................................................................................................................ 51
7 Profiles and Multiple Network Support .............................................................. 52
7.1 Introduction to Profiles .......................................................................................................... 52 7.2 Transmit Profiles ................................................................................................................... 52 7.3 Receive Profiles .................................................................................................................... 53
8 Parameter Reference ......................................................................................... 54
8.1 SMS Service ......................................................................................................................... 54 8.1.1 SMS Deliver parameters ............................................................................................ 55
8.2 Atomic SMS-MT Service ......................................................................................................... 56 8.3 MO-SMS Service ................................................................................................................... 56
8.3.1 SMS Submit parameters ............................................................................................ 57 8.4 Alert Service Centre Service ................................................................................................... 58 8.5 Send Routing Info For SM Service ........................................................................................... 58
8.5.1 Inform Service Centre parameters .............................................................................. 59 8.6 Report SM Delivery Status Service .......................................................................................... 60 8.7 USSD Service ....................................................................................................................... 61 8.8 Location Service ................................................................................................................... 62
8.8.1 Cell Id Parameters .................................................................................................... 62 8.9 Subscriber State Service ........................................................................................................ 63 8.10 Get IMSI Service .................................................................................................................. 64 8.11 Error ................................................................................................................................... 65
8.11.1 Error Code Types...................................................................................................... 65 8.11.2 Error Code Type – internalFailureCodeType ................................................................. 65 8.11.3 Error Code Type – mapErrorCodeType ........................................................................ 65 8.11.4 Error Code Type – userErrorCodeType ........................................................................ 67 8.11.5 Error Code Type – providerErrorCodeType ................................................................... 67 8.11.6 MAP User Errors ....................................................................................................... 67
9 Application Development Guidelines ................................................................. 70
9.1 Application Development Frameworks ..................................................................................... 70 9.2 XML Handling ....................................................................................................................... 70 9.3 HTTP/HTTPS ........................................................................................................................ 70 9.4 Use of Expect: HTTP 100 – Continue ....................................................................................... 70
10 Application Examples ........................................................................................ 71
10.1 Java SWS Test Utility ............................................................................................................ 71
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
5
10.2 C# SWS Example Application ................................................................................................. 72 10.3 PHP Example ........................................................................................................................ 73
Appendix A. XSD Files ............................................................................................. 74
A.1 SWS XSD Schema ................................................................................................................. 74
Appendix B. Testing Extensions to the API ............................................................. 88
B.1 Receiving Atomic Send Routing Info For SM ............................................................................. 88 B.2 Receiving Ready For SM ......................................................................................................... 89 B.3 Receiving Report SM Delivery ................................................................................................. 91 B.4 Receiving Location Request .................................................................................................... 92 B.5 Receiving Subscriber State Request ........................................................................................ 93 B.6 Transmitting Alert Service Centre Request ............................................................................... 95 B.7 Receiving Get IMSI Request ................................................................................................... 96
Figures Figure 1: Single SWS ...................................................................................................................... 10 Figure 2: Signaling Paths in a Dual Resilient Configuration ................................................................... 11 Figure 3: Single SWS Connected to SSP/SCP or STP ........................................................................... 11 Figure 4: SWS Dual Configuration with Connections to SSP/SCP ........................................................... 12 Figure 5: SWS Dual Configuration with Connections to STP .................................................................. 12 Figure 6: SWS Dual Configuration with Connections to Mated STP Pair ................................................. 13 Figure 7: Module IDs for Use with Multiple Network Contexts .............................................................. 14 Figure 8: Interfaces ........................................................................................................................ 17 Figure 9. Sending an SMS (Network Diagram) .................................................................................... 19 Figure 10: Sending an SMS (Full Message Flow without Report SM Delivery) .......................................... 24 Figure 11: Sending an SMS (Full Message Flow with Report SM Delivery) .............................................. 25 Figure 12: Receiving an SMS ............................................................................................................ 26 Figure 13: Sending a concatenated SMS ............................................................................................ 29 Figure 14: Receiving a concatenated SMS .......................................................................................... 30 Figure 15: Transmitting an Atomic MT-SMS........................................................................................ 33 Figure 16: Transmitting a Concatenated atomic MT-SMS ..................................................................... 35 Figure 17: Transmitting a Send Routing Info For SM ........................................................................... 36 Figure 18: Transmitting a Report SM Delivery .................................................................................... 37 Figure 19: Transmitting a Ready For SM ............................................................................................ 38 Figure 20: Receiving a Send Routing Info For SM ................................................................................ 40 Figure 21: Receiving Alert Service in Auto Mode ................................................................................. 41 Figure 22: Receiving Alert Service in Abort Mode ................................................................................ 42 Figure 23: Receiving an Alert Service Request in Manual Mode ............................................................. 42 Figure 24: Mobile Originated USSD session ........................................................................................ 44 Figure 25: Application Originated USSD session .................................................................................. 46 Figure 26: Application Originated USSD session – with USSD Notify ...................................................... 47 Figure 27: Sending a USSD Notify..................................................................................................... 48 Figure 28: Requesting a mobile location ............................................................................................ 49 Figure 29: Requesting a mobile subscriber state ................................................................................. 50 Figure 30: Requesting the IMSI from the HLR..................................................................................... 51 Figure 31: Java SMS Test Sender...................................................................................................... 71 Figure 32: C# Test Sender ............................................................................................................... 72
Contents
6
Figure 33: PHP Test Sender ............................................................................................................. 73 Figure 34: Receiving a Send Routing Info For SM................................................................................ 88 Figure 35: Receiving a Ready For SM ................................................................................................ 89 Figure 36: Receiving a Report SM Delivery ......................................................................................... 91 Figure 37: Receiving a Location Request ............................................................................................ 92 Figure 38: Receiving a subscriber state Request ................................................................................. 93 Figure 39: Transmitting a Alert Service Centre ................................................................................... 95 Figure 40: Receiving a Get IMSI Request ........................................................................................... 96
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
7
1 Introduction
The Dialogic® DSI Signaling Interface for Web-Services (SWS) allows access to SS7 and SIGTRAN signaling functionality via the use of a set of web-services high-level APIs. This document focuses on defining the APIs, offering information about developing new applications and providing details of the sample applications that are used to show the API being implemented.
1.1 Signaling Service Support The services supported are focused on three areas:
Short Messaging (SMS)
This provides the ability to send SMS messages to mobile devices based on the mobile number with a simple API call. It enables SMS advertisements,
SMS information services and many other types of services. The API also supports the reception of SMS messages to enable SMS voting applications or activation of other services via SMS.
The normal SMS API call will both perform a routing look-up and send the SMS. If the user requires further control of the separate parts of this procedure then a set of 'atomic' API calls are available to support this.
Unstructured Supplementary Service Data (USSD)
The Unstructured Supplementary Service Data (USSD) function is part of the GSM mobile specifications and permits arbitrary data to be sent and received by compatible mobile devices for such services as mobile top-up menus and information retrieval (e.g., what is the mobile device's number). The API
supports both mobile-originated sessions and application-initiated sessions.
Location Based services
The SWS allows the application to request the location of a mobile station using the MSISDN number via mobile network access. of the mobile station will be returned in the response, giving its longitude and latitude.
1.2 Feature Overview
High Level Application API – simplified interface
Lowers SS7 / GSM MAP protocol knowledge required
Focuses on enabling common services to mobile devices
XML / HTTP Web Service API
Client systems not restricted in language/OS support
Wide range of tool support
1.3 Abbreviations ANSI American National Standards Institute
1 Introduction
8
GPRS General Packet Radio Service
ITU-T International Telecommunication Union (formerly CCITT)
MAP Mobile Application Part
MTP Message Transfer Part
REST Representational State Transfer
SCCP Signaling Connection Control Part
SMS Short Message Service
SWS Dialogic® DSI Signaling Interface for Web-Services
TCAP Transaction Capabilities Application Part
TP Transfer Protocol
USSD Unstructured Supplementary Service Data
WS Web-service
1.4 Related Information Refer to the following for related information:
Dialogic® DSI Signaling Servers SS7G41 Operators Manual
Dialogic® DSI Signaling Servers SS7G41 Hardware Manual
Dialogic® DSI Components Software Environment Programmer’s Manual
The following manual(s) should be read depending on the protocol options installed on the server:
SCCP Programmer’s Manual
TCAP Programmer’s Manual
MAP Programmer’s Manual
SCTP Programmer’s Manual
M3UA Programmer’s Manual
M2PA Programmer’s Manual
MAP GSM specifications
3GPP TS 23.040
3GPP TS 23.030
3GPP 29.002
This manual is applicable to SS7G41 with SWS Mode Release 1.3.0 or later.
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
9
2 SWS Mode Overview
2.1 Architecture Overview The Dialogic® DSI Signaling Server for Web-Services (SWS) allows client applications to offer services which make use of SMS, USSD and location
functionality. The SWS unit connects into SS7 or SIGTRAN networks and provides APIs to allow one or more instance of a client application to control this functionality. The SS7 configuration parameters are specified in a text file contained within each SWS.
A complete system requires, in addition to the SWS unit, at least one active
client application. The client applications communicate with the SWS using a web-service interface. For a description of the client applicator development
APIs. Refer to section 3 Web Services APIs.
2 SWS Mode Overview
10
2.1.1 Signaling Topologies
A single SWS may be used standalone, or two units may be configured in a dual resilient configuration. Each SWS may support one or more application (host) computers.
The host computer contains the physical resources controlled by the
signaling, such as voice circuits and databases. The SWS extracts SS7 information and conveys it to the application software, which can control the resource accordingly and issue the required responses to the SWS for transport over the SS7 network.
The minimal system consists of a single SWS connected to a single host via
Ethernet as illustrated below. Dashed lines indicate optional equipment.
Figure 1: Single SWS
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
11
This system may be scaled up at initial system build time or later to a dual resilient configuration connected to the maximum number of hosts supported. See the figure below:
Figure 2: Signaling Paths in a Dual Resilient Configuration
The SWS may connect to a number of adjacent signaling points, the
maximum number being limited only by the maximum number of link sets supported by the unit. The adjacent SS7 nodes may be Signaling Transfer Points (STPs), Signaling Switching Points (SSPs) or Signaling Control Points (SCPs). The following diagrams indicate possible configurations, although these are not exhaustive. The figure below shows a single SWS connected to an adjacent SSP/SCP and/or STP.
Figure 3: Single SWS Connected to SSP/SCP or STP
In a dual resilient configuration, the SWS pair share the same SS7 point code. The figure below shows an SWS pair connected to a single adjacent SSP/SCP.
2 SWS Mode Overview
12
Figure 4: SWS Dual Configuration with Connections to SSP/SCP
The SWS pair may also be connected to a single adjacent STP (or
combination of SSP and STP) as shown below:
Figure 5: SWS Dual Configuration with Connections to STP
The figure below shows an SWS pair connected to a “mated” STP pair. In this configuration, all the links from the first STP must be terminated at SWSA and all the links from the second STP must be terminated at SWSB.
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
13
Figure 6: SWS Dual Configuration with Connections to Mated STP Pair
2.2 Multiple Network Support The SS7 Network Context together with a signaling point code uniquely
identifies an SS7 node by indicating the specific SS7 network it belongs to. The Network Context may be a unique identifier for a physical SS7 network, for example, to identify an ANSI, ITU, International or National network, or it may be used to subdivide a physical SS7 network into logical sub-networks.
The Signaling Server supports up to four Network Contexts where each Network Context is a different network or different independent local point code within the same network. Selection of which Network context to use is
made when configuring an SWS Profile.
In the configuration commands or MMI commands, Network Contexts are designated NC0, NC1, NC2 or NC3.
2.2.1 Protocol Handling for Multiple Network Contexts
The figure below shows the use of multiple Network Contexts from an
application perspective and provides examples of the module IDs for the various application layers.
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
15
2.2.2 Inter-SWS Communications
In a dual resilient configuration (one unit nominated as SWSA, the other as SWSB), two physically independent communication channels exist between the two units.
Control information is exchanged over the Ethernet. Signaling messages are
exchanged (when necessary) over an inter-SWS SS7 link set, which must be configured for correct dual resilient operation.
The preferred route for messages transmitted from an SWS is over the links connecting that unit to the appropriate adjacent point code (a point code that is either the final destination or a route to the final destination). If no
signaling link to an appropriate adjacent point code is available, the transmit
traffic is passed to the other SWS via the inter-SWS link set. If the inter-SWS link set fails, transmit messages fall back to being passed over the Ethernet.
If the inter-SWS link set fails (causing the Ethernet link to be used for transmitted messages), message loss may occur at the point where the preferred route fails.
The SS7 network is free to deliver received messages to either SWS. Special processing at the User Part level ensures that any message received for a call
or transaction being handled by the other unit is routed over the Ethernet.
The inter-SWS link set is configured in the same manner as normal link sets, for details, refer to Configuration in the Dialogic® DSI Signaling Servers SS7G41 Operators Manual.
The inter-SWS link set may consist of one or more signaling links configured on one or more signaling ports (T1/E1), distributed between one or more signaling boards. Resilience on the Inter SWS link set may be achieved by
configuring two links in the inter-SWS link set, each on a separate signaling board. The inter-SWS link may also be conveyed over M2PA or M3UA avoiding the requirement for a TDM link and cabling between the units.
2.2.3 Transaction-Based Applications
Applications that need to exchange non-circuit related information over the SS7 network (such as for the control of a Mobile Telephone Network or for an Intelligent Network application) do so by exchanging information between sub-systems using the services of SCCP. A sub-system is an entity that exchanges data with other entities by using SCCP.
The SWS provides the capability to configure local sub-systems and routing to remote resources. The intelligent functionality of each local sub-system is
provided by the user application running on one or more host computers.
2.2.4 Management of Local SCCP Sub-Systems
The SWS system automatically brings local SCCP sub-systems into service, no application interaction is required.
2 SWS Mode Overview
16
2.2.5 Alarms
The Dialogic® DSI Signaling Server products are able to detect a number of events or alarm conditions relating to either the hardware or the operation of the protocols. Each alarm condition is assigned a severity/class (3=Critical, 4=Major, 5=Minor) and a category and ID, which give more detail about the
alarm. There are a number of mechanisms described below, by which these conditions can be communicated to management systems, and ultimately to the system operator. See Alarm Listing in the Dialogic® DSI Signaling Servers SS7G41 Operators Manual for a list of alarm types, and their reporting parameters.
Active alarms are indicated on the front panel of the Signaling Server with
three LEDs identifying severity; CRT, MJR, MNR.
Active alarms may be indicated remotely from the Signaling Server when the alarm relay outputs are connected to a remote management system.
Alarm events (occurrence and clearing, class, category and ID) may be reported via Management messages to the host application thus permitting remote monitoring and/or logging.
Alarm events may be reported to an SNMP manager. SNMP support is
described in SNMP in the Dialogic® DSI Signaling Servers SS7G41 Operators Manual.
A system operator can obtain a listing of the current alarm status (CLA, CATEGORY, ID and TITLE) using the ALLIP management terminal command described in ALLIP in the Dialogic® DSI Signaling Servers SS7G41 Operators Manual. Test Critical, Major, or Minor may be activated using the ALTEI management command and cleared using the ALTEE
management command.
2.3 Interfaces The SWS offers a number of interfaces, which are described below:
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
17
Web Services
Application
Application
Manager
Management
Terminal (MMI)
Dialogic®
DSI
Signaling
Interface for Web
Services
Telnet OA&M
Web B
rowser
App O
A&M
We
b S
erv
ice
s
AP
P A
PI
Figure 8: Interfaces
2.3.1 Application Interface
This interface allows client systems to make use of the high-level service-specific API to simplify access to signaling services in the mobile network.
This is done via a web-service API, as detailed Web Services APIs.
2.3.2 Configuration Interface
The SWS can configure many aspects of system operation and signaling functionality. Such configuration is performed for the SS7 stack via a static configuration file on the SWS system. The control of the high-level API and
API service specific functionality is provided via a Web-services based interface, which can be controlled in a browser.
2 SWS Mode Overview
18
Note: System configuration ins described in detail in the Dialogic® DSI Signaling Servers SS7G41 Operators Manual.
2.3.3 Management Interface, Trace, and Diagnostics
The SWS can provide tracing and diagnostic information from modules in the system. This can include tracing at different levels of the protocol stack. The
Man-Machine Interface (MMI) can also be used to provide status and statistics from the system.
Tracing of the Web-service API can be achieved via tools such as Wireshark run on the client system.
2.3.4 Network Interfaces
Internal to the SWS system, the high-level API makes use of other layers of the SS7 stack such as MAP, TCAP and SCCP. The SWS will also connect to the signaling network via the TDM SS7 MTP3 module or SIGTRAN modules such as M3UA or M2PA.
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
19
3 Web Services APIs
3.1 Overview The web-services interface uses HTTP with an XML payload using a REST architecture. This makes it suitable for implementation on a large number of
client systems using different OSs, languages and frameworks. The diagram below shows an example usage of the SWS with the network elements and message flow.
Network B
Network A
Client
Application
MSC/VLR
HLR
Mobile
Mobile
DSI SWS
BSS
MSC/VLR
HLR
BSS
1 2
3
4
5
67
8
Figure 9. Sending an SMS (Network Diagram)
1 – SMS Request (HTTP PUT)
2 – Send Routing Info for SM Request
3 – Routing Response
4, 5 – Forward Short Message (MT)
6, 7 – Forward Short Message Response (MT)
8 – SMS Response (HTTP PUT Response – 204 No Content)
3 Web Services APIs
20
3.2 Summary
3.2.1 Supported URIs / Methods
All URIs are preceded by the domain and root “/dialogicwebservice/signaling” or “/dialogicwebservice/signaling/profile/<profile_name> (only the initial message should contain the profile). See Section 7 - Profiles and Multiple Network Support for further details on profile support.
If the profile resource is absent then this is equivalent as using the profile for the service with ID that matches 0.
URL Method Action
/<msisdn>/sms PUT Requests an SMS be transmitted
/<msisdn>/sms POST Requests an SMS be transmitted and maintain a dialog open for further SMS to the same mobile.
/<msisdn>/sms/<sessionid> PUT Continuation of an SMS to be transmitted
/sms GET Receive new SMS
/sms/<sessionid> GET Continuation of receiving an SMS
/<msisdn>/smsmo PUT Requests a mobile originated SMS be
transmitted
/smsmp GET Receive a new mobile originated SMS
/<msisdn>/location GET Requests location information
/ussd POST Requests setup of a new application initiated USSD session and a session id is returned.
/ussd GET Receive new mobile initiated USSD session. A session id is returned.
/ussd PUT Sends USSD data to mobile without creating a session using a USSD Notify
/ussd/<sessionid> PUT Sends data, response contains user reply
/ussd/<sessionid > DELETE Ends or aborts a session
/<msisdn>/sriforsm GET Requests a Send Routing Info For Short Message to be transmitted
/alertsc GET Requests a new service centre alert
/<msisdn>/readyforsm PUT Requests a new Ready For SM to be transmitted
/<msisdn>/smsmt PUT Requests an atomic mobile terminated SMS to be transmitted
/<msisdn>/reportsmdeliver PUT Requests a report SM Deliver to be transmitted
All others ANY Return Status 404: Not Found
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
21
Example:
To send an SMS to the mobile number +44 7777 123456, call an HTTP PUT with the URI:
http://192.168.0.1/dialogicwebservice/signaling/447777123456/sms
To send an SMS to the mobile number +44 7777 123456 using profile TX_SMS_0, call an HTTP PUT with the URI:
http://192.168.0.1/dialogicwebservice/signaling/profile/TX_SMS_0/
447777123456/sms
Note: The MSISDN should include the country code but should not include a ‘+’ or other leading dial prefix.
3.2.2 Payload Structure
The payload is XML encoded with the following general form. This includes a version identifier used to aid compatibility between schema versions. The encoding scheme expected in requests and used by the SWS is UTF-8.
<?xml version="1.0" encoding=’UTF-8’?>
<primitive_type version=”n”>
<parameter1> </parameter1>
<parameter2> </parameter2>
</primitive_type>
3.2.3 HTTP Response Codes
The following set of HTTP response codes are used
Response Code
HTTP Meaning Used when
200 OK Request was processed successfully; the result of the request is contained within the XML body of the response
201 Created Session created
204 No Content Request was successful; no additional content required
400 Bad Request The request could not be parsed
401 Unauthorized A required authentication method was not used
403 Forbidden Invalid resource requested
404 Not Found An invalid method was requested
500 Internal Server Error
The requested method could not be performed due to an error detected at the server
504 Gateway Timeout Service timed-out at the server
3 Web Services APIs
22
3.3 MAP Services Used The SWS system makes use of a number of GSM MAP Services implemented in the underlying SS7/SIGTRAN stack. The table below summarizes these
services used.
API Call Method MAP
Services Used
Notes
/<msisdn>/sms PUT SendRoutingInfoForSM
ForwardSM
ReportSMDelivery
ReportSMDelivery is only sent if configured.
/<msisdn>/sms POST SendRoutingInfoForSM
ForwardSM
/<msisdn>/sms/<sessionid> PUT ForwardSM
ReportSMDelivery
ReportSMDelivery is only sent if configured.
/sms GET ForwardSM
/sms/<sessionid> GET ForwardSM
/<msisdn>/smsmo PUT ForwardSM MO
/smsmo GET ForwardSM MO
/<msisdn>/location GET AnyTime Interrogation
/ussd POST USSD Request
/ussd GET ProcessUnstructred
USSD Request
/ussd PUT USSD Notify
/ussd/<sessionid> PUT USSD Request / Notify
/ussd/<sessionid > DELETE TCAP-End
/<msisdn>/sriforsm GET SendRoutingInfoForSM
InformSC
InformSC is processed if received from the network in response to the send routing info request
/alertsc GET AlertSerivceCentre
/<msisdn>/readyforsm PUT ReadyForSM
NoteSubscriberPresent
ReadyForSM is sent by default, but if configured NoteSubscriberPresent can be sent instead (Version 1 Operation)
/<msisdn>/smsmt PUT ForwardSM
/<msisdn>/reportsmdeliver PUT ReportSMDelivery
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
23
4 Short Message API
The SMS API has two methods, one for permitting the transmission of an SMS message to a mobile device and the second for reception of a message by the SWS system.
URL Method Action
/<msisdn>/sms PUT Requests an SMS be transmitted
/<msisdn>/sms POST Requests an SMS be transmitted and maintain a dialog open for further SMS to the same mobile.
/<msisdn>/sms/<sessionid> PUT Continuation of an SMS to be transmitted
/sms GET Receive new SMS
/sms/<sessionid> GET Continuation of receiving an SMS
/<msisdn>/smsmo PUT Requests a mobile originated SMS be
transmitted
/smsmp GET Receive a new mobile originated SMS
/<msisdn>/sriforsm GET Requests a Send Routing Info For Short Message to be transmitted
/alertsc GET Requests a new service centre alert
/<msisdn>/readyforsm PUT Requests a new Ready For SM to be transmitted
/<msisdn>/smsmt PUT Requests an atomic mobile terminated SMS to be transmitted
/<msisdn>/reportsmdeliver PUT Requests a report SM Deliver to be transmitted
4.1 Sending an SMS To send an SMS message to a mobile device use the mobile number in the
URI and an HTTP PUT as shown in Figure 10: Sending an SMS (Full Message Flow without Report SM Delivery):
4 Short Message API
24
Client SWS Mobile
Foward Short Message
Forward Short Message - Reponse
PUT
HLR VLR/MSC
Send Routing Info for SM
Send Routing Infor for SM - Reponse
Figure 10: Sending an SMS (Full Message Flow without Report SM Delivery)
When sending the SMS in step 1, the payload XML should have the form
shown below. See Chapter 10, “XSD Files” for the supporting XSD schema.
MT-FORWARD-SHORT-MESSAGE-TX-REQ
<?xml version="1.0" encoding="utf-8"?>
<!—- Example SMS sent -->
<sms version="1">
<message encodingScheme="0" language="en-GB">Hello</message>
<dest noa="1" np="1">447777123456</dest>
<orig noa="1" np="1">447777654321</orig>
</sms>
In the response there will be an appropriate response code, as shown in section 3.2.3 HTTP Response Codes.
Note: The 204 – No Content response code is the expected response to a successfully sent SMS message.
If the error code is returned, it will take the following form:
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
25
<?xml version="1.0" encoding="utf-8"?>
<!-- Example Error Code -->
<error>
<code type=”MapUserError”>SystemFailure</code>
<text>TX-MO-SMS(FSM) System Failure</text>
</error>
4.1.1 Support for Report SM Delivery
It is possible to set the SWS system to send an automatic report SM Delivery
to the HLR via the configuration option “Automatic ReportSMDelivery” on the Web MMI. This optional can be found under “System Administration -> MAP Services -> SMS -> Configuration”. It can also be set using the equivalent
MMI command MASMS and the RDEL parameter.
Client SWS Mobile
Foward Short Message
Forward Short Message - Reponse
200 - OK
PUT
HLR VLR/MSC
Send Routing Info for SM
Send Routing Infor for SM - Reponse
Report SM Delivery
Report SM Delivery - Reponse
Figure 11: Sending an SMS (Full Message Flow with Report SM Delivery)
4 Short Message API
26
4.2 Receiving an SMS To collect the next outstanding SMS message received by the SWS use a HTTP GET with a URI of the form as shown below in Figure 12: Receiving an
SMS
HTTP GET
http://192.168.0.1:81/dialogicwebservice/signaling/sms
Client SWS Mobile
Foward Short Message - Response
Forward Short Message200 - OK
GET
Figure 12: Receiving an SMS
The response should include a 200 OK for success. In other cases an appropriate response code will be used as shown in section 3.2.3 HTTP Response Codes.
The returned response will have XML payload of the following form:
<?xml version="1.0" encoding="utf-8"?>
<!-- Example SMS received -->
<sms version="1">
<message">Goodbye</message>
<orig ton="International" np="ISDN">447777654321</orig>
<imsi>987654321</imsi>
</sms>
Alternatively an HTTP response code, error codes and text will be returned.
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
27
4.3 Sending a binary format SMS In order to support services requiring more control over the SMS and the format it is sent in the API also supports direct control over the SMS-Deliver
short message transfer protocol data unit as defined in the GSM specifications such as 3GPP TS 23.040 version 9.3.0 Release 9.
In order to send using this format the message element should be replaced with the smsDeliver element. This element is a compound parameter made up of the TP sub-parameters defined to match those in the SMS Deliver structure in the GSM specifications. The TP-UD parameter contains the Unit
Data of the SMS encoded as Base 64. The other elements of the smsDeliver
element control the formatting and additional data relating to the SMS payload.
An example of this format is shown below. These elements are specified in more detail in section 8.1.1.
<?xml version="1.0" encoding="UTF-8"?>
<sms version="1">
<dest ton="Subscriber" npi="ISDN">447777123456</dest>
<smsDeliver>
<mms>false</mms>
<rp>false</rp>
<udhi>false</udhi>
<udl>57</udl>
<sri>true</sri>
<dcs>0</dcs>
<pid>4</pid>
<scts>EUBgAhFyAA==</scts>
<ud>zLe83Aal4fN6G0R+s99y0DxNB4XbZToLNH675+UxvUyvy0FhchqenqfHafcZV
Gan6S4=</ud>
</smsDeliver>
</sms>
4 Short Message API
28
4.4 Receiving a binary format SMS The SWS can also receive messages in a binary SMS format.
The SMS Service Options section of the SMS Configuration Tab of the web
management interface contains a control which selects the handling of non-simple text SMS. The control has the following meaning
Receive only SMS text:
All SMS which can be returned using the simple message format will be sent in that format. All other SMS will be sent as binary SMS format.
Receive SMS network headers
All SMS will be returned as binary format using the smsDeliver element.
The parameters and meanings are the same as for the sending of binary format SMS.
<?xml version="1.0" encoding="UTF-8"?>
<sms version="1">
<orig ton="International" npi="ISDN">447777654321/orig>
<imsi>987654321</imsi>
<smsDeliver>
<mms>false</mms>
<rp>false</rp>
<udhi>false</udhi>
<udl>57</udl>
<sri>true</sri>
<dcs>0</dcs>
<pid>4</pid>
<scts>EUBgAhJlAA==</scts>
<ud>zLe83Aal4fN6G0R+s99y0DxNB4XbZToLNH675+UxvUyvy0FhchqenqfHafcZV
Gan6S4=</ud>
</smsDeliver>
</sms>
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
29
4.5 Sending a concatenated binary format SMS
Figure 13: Sending a concatenated SMS
In order to send a user concatenated message the user must be making use of the binary message format as discussed in section 4.3. In order to request additional messages to be sent in the same dialog the client application should set the mms (More Messages to Sent) parameter to ‘true’. When the SWS responds to the initial SMS being sent it will then include a session identifier which can be used to link later SMS requests to the first. The last
message in the dialog should be sent with the mms parameter set to ‘false’.
The URIs used for a two concatenated SMS would be as follows:
HTTP POST
http://<server>:81/dialogicwebservice/signaling/<msisdn>/sms
HTTP PUT
http://<server>:81/dialogicwebservice/signaling/<msisdn>/sms/<ses
sionId>
For example:
4 Short Message API
30
HTTP POST
http://192.168.0.1:81/dialogicwebservice/signaling/447777123456/s
ms
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/447777123456/s
ms/5
Note: The MMS (More Messages to Send) field in the SMS-Deliver TP parameter takes the value of 1 in the encoded message sent over the SS7 link or SIGTRAN association if there are no more messages to send. A value of 0 indicates there are more messages to send. The SWS API uses a value of ‘true’ when there are more messages and ‘false’ when there are no more messages to send.
4.6 Receiving a concatenated binary format SMS
Client SWS Mobile
Foward Short Message - Response
Forward Short Message (More Messages)200 - OK
GET (sms)
Foward Short Message - Response
Forward Short Message (No More Messages)200 - OK
GET (sms/<sessionId>)
Figure 14: Receiving a concatenated SMS
Receiving a concatenated SMS takes a similar approach to that of sending a concatenated SMS in that a session id is returned in order to allow related concatenated SMS to be returned together and collected from the SWS.
The URIs used for receiving two concatenated SMS would be as follows:
HTTP GET
http://<server>:81/dialogicwebservice/signaling/sms
HTTP GET
http://<server>:81/dialogicwebservice/signaling/sms/<sessionId>
For example:
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
31
HTTP GET
http://192.168.0.1:81/dialogicwebservice/signaling/sms
HTTP GET
http://192.168.0.1:81/dialogicwebservice/signaling/sms/5
4.7 Mobile Originated SMS Transmitting or Receiving Mobile Originated SMS must be performed using the binary format (see sections 4.3 and 4.4).
In order to send a mobile originated SMS the user must use the SMS-Submit
short message transfer protocol data unit as defined in the GSM specifications such as 3GPP TS 23.040 version 9.3.0 Release 9.
The following is an example of this format. These elements are specified in
more detail in Section 8.1 SMS Service.
Example
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/447777123456/s
msmo
<?xml version="1.0" encoding="UTF-8"?>
<sms version="1">
<orig ton="International" npi="ISDN">447777654321/orig>
<msc ton="International" npi="ISDN">32143332542/msc>
<destSrvCtr ton="Unknown" npi="ISDN">4235432543/destSrvCtr>
<dest ton="International" npi="ISDN">447777654322/dest>
<smsSubmit>
<rd>false</rd>
<rp>false</rp>
<udhi>false</udhi>
<udl>57</udl>
<srr>true</srr>
<mr>2</mr>
<dcs>0</dcs>
<pid>4</pid>
<tpRel>20</tpRel>
<ud>zLe83Aal4fN6G0R+s99y0DxNB4XbZToLNH675+UxvUyvy0FhchqenqfHafcZV
Gan6S4=</ud>
</smsSubmit>
</sms>
4 Short Message API
32
Receiving an MO-SMS is similar to receiving a binary message as discussed in section 4.4 Receiving a binary format SMS.
HTTP GET
http://192.168.0.1:81/dialogicwebservice/signaling/smsmo
<?xml version="1.0" encoding="UTF-8"?>
<sms version="1">
<orig ton="International" npi="ISDN">447777654321/orig>
<msc ton="International" npi="ISDN">32143332542/msc>
<destSrvCtr ton="Unknown" npi="ISDN">4235432543/destSrvCtr>
<dest ton="International" npi="ISDN">447777654322/dest>
<smsSubmit>
<rd>false</rd>
<rp>false</rp>
<udhi>false</udhi>
<udl>57</udl>
<srr>true</srr>
<mr>2</mr>
<dcs>0</dcs>
<pid>4</pid>
<tpRel>20</tpRel>
<ud>zLe83Aal4fN6G0R+s99y0DxNB4XbZToLNH675+UxvUyvy0FhchqenqfHafcZV
Gan6S4=</ud>
</smsSubmi
4.8 Sending Atomic MT-SMS To send an SMS message to a mobile device use the mobile number in the URI and an HTTP PUT as shown below in Figure 15: Transmitting an Atomic
MT-SMS:
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
33
Client SWS Mobile
Foward Short Message
Forward Short Message - Reponse200 - OK
PUT
HLR VLR/MSC
Figure 15: Transmitting an Atomic MT-SMS
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/447777123456/s
msmt
The payload XML should have the form shown below. See Appendix A.1 for the supporting XSD schema.
MT-FORWARD-SHORT-MESSAGE-TX-REQ
<?xml version="1.0" encoding="utf-8"?>
<!—- Example SMS sent -->
<smsmt version="1">
<message>Hello</message>
<imsi>5012423432</imsi>
<msc ton="International" np="ISDN">440044001122</msc>
<orig ton="International" np="ISDN">447777654321</orig>
</smsmt>
In the response there will be an appropriate response code, as shown in section 3.2.3.
The 204 – No Content response code is the expected response to a successfully sent SMS message. If an error response code is returned, it will have payload of the following form:
<?xml version="1.0" encoding="utf-8"?>
<!-- Example Error Code -->
<error>
<code type=”MapUserError”>SystemFailure</code>
<text>Error Text</text>
</error>
4 Short Message API
34
4.9 Sending a binary format Atomic MT-SMS In order to send a user concatenated message the user must be making use of the binary message format as discussed in section 4.3.
An example of this format is shown below. These elements are specified in more detail in section 8.1.1.
<?xml version="1.0" encoding="UTF-8"?>
<smsmt version="1">
<imsi>234153121235437</imsi>
<msc ton="International" np="ISDN">440044001122</msc>
<smsDeliver>
<mms>false</mms>
<rp>false</rp>
<udhi>false</udhi>
<udl>57</udl>
<sri>true</sri>
<dcs>0</dcs>
<pid>4</pid>
<scts>EUBgAhFyAA==</scts>
<ud>zLe83Aal4fN6G0R+s99y0DxNB4XbZToLNH675+UxvUyvy0FhchqenqfHafcZV
Gan6S4=</ud>
</smsDeliver>
</sms>
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
35
4.10 Sending Concatenated Atomic MT-SMS
Client SWS Mobile
Foward Short Message
Forward Short Message - Reponse200 - OK
POST (smsmt)
HLR VLR/MSC
PUT (smsmt/sessionid) Foward Short Message
Forward Short Message - Reponse200 - OK
Figure 16: Transmitting a Concatenated atomic MT-SMS
In order to send a user concatenated message the user must be making use of the binary message format as discussed in section 4.3. In order to request additional messages to be sent in the same dialog the client application should set the mms (More Messages to Sent) parameter to ‘true’. When the SWS responds to the initial SMS being sent it will then include a session identifier which can be used to link later SMS requests to the first. The last
message in the dialog should be sent with the mms parameter set to ‘false’.
The URIs used for a two concatenated SMS would be as follows:
HTTP POST
http://<server>:81/dialogicwebservice/signaling/<msisdn>/smsmt
HTTP PUT
http://<server>:81/dialogicwebservice/signaling/<msisdn>/smsmt/<s
essionId>
4 Short Message API
36
For example:
HTTP POST
http://192.168.0.1:81/dialogicwebservice/signaling/447777123456/s
msmt
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/447777123456/s
msmt/5
4.11 Sending Atomic Send Routing Info For SM A client can request that a Send Routing Info For SM be used sent to the HLR. This uses a HTTP PUT request and similar XML payload to the other SMS APIs. See the Figure 27: Sending a USSD Notify below:
Client SWS
200 - OK
PUT
HLR
Send Routing Info for SM
Send Routing Infor for SM - Reponse
Figure 17: Transmitting a Send Routing Info For SM
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/<msisdn>/srifo
rsm
The payload is optional depending on whether the default Type of Number or the Numbering Plan needs to be overridden or any optional fields are required, if so then the XML should have the form shown below. See
Appendix A.1 for the supporting XSD schema.
SEND-ROUTING-FOR-SM-TX-REQ
<?xml version="1.0" encoding="utf-8"?>
<!—- Example SRI sent -->
<sriForSm version="1">
<msisdn ton="International" np="ISDN">447777654321</msisdn>
</sriForSm >
The response should include a 200 OK for success. In other cases an appropriate response code will be used as shown in section 3.2.3.
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
37
The returned response will have XML payload of the following form:
<?xml version="1.0" encoding="utf-8"?>
<!-- Example SMS received -->
<sriForSm version="1">
<imsi>5012423432</imsi>
<msc ton="International" np="ISDN">440044001122</msc>
</sriForSm>
4.12 Sending Atomic Report SM Delivery A client can request that to transmit a Report SM Delivery to be used sent to the HLR. This uses a HTTP PUT request and similar XML payload to the other SMS APIs. See the Figure 27: Sending a USSD Notify below:
Client SWS
200 - OK
PUT
HLR
Report SM Delivery
Report SM Delivery - Response
Figure 18: Transmitting a Report SM Delivery
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/<msisdn>/repor
tSMDeliver
The payload is required and the XML should have the form shown below. See Appendix A.1 for the supporting XSD schema.
4 Short Message API
38
REPORT-SM-DELVIER-TX-REQ
<?xml version="1.0" encoding="utf-8"?>
<!—- Example SRI sent -->
<reportSMDeliver version="1">
<msisdn ton="International" np="ISDN">447777654321</msisdn>
<deliveryOutcome>successfulTransfer</deliveryOutcome>
</reportSMDeliver>
The 204 – No Content response code is the expected response to a successfully sent Report SM Delivery message, unless the HLR returns a Stored MSISDN in which case a 200-OK will be returned containing the MSISDN. If an error response code is returned, it will have payload of the
following form:
<?xml version="1.0" encoding="utf-8"?>
<!-- Example Error Code -->
<error>
<code type=”MapUserError”>SystemFailure</code>
<text>Error Text</text>
</error>
4.13 Sending Atomic Ready For SM A client can request that to transmit a Ready For SM (Note Subscriber Present MAP Version 1) to be used sent to the HLR. This uses a HTTP PUT request and similar XML payload to the other SMS APIs. See the Figure 27: Sending a USSD Notify below:
Client SWS
200 - OK
PUT
HLR
Ready For Sm
Ready For Sm - Response
Figure 19: Transmitting a Ready For SM
The payload is required and the XML should have the form shown below. See Appendix A.1 for the supporting XSD schema.
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
39
Client SWS
200 - OK
GET
SMSC
Send Routing Info for SM
Send Routing Info for SM - ResponsePUT
200 - OK
READY-FOR-SM-TX-REQ
<?xml version="1.0" encoding="utf-8"?>
<!—- Example SRI sent -->
<readyForSm version="1">
<imsi>234153121235437</imsi>
<alertReason>msPresent</alertReason>
<hlrAddr ton="International" np="ISDN">440044001122</ hlrAddr >
</readyForSm>
The 204 – No Content response code is the expected response to a successfully sent Report SM Delivery message. If an error response code is returned, it will have payload of the following form:
<?xml version="1.0" encoding="utf-8"?>
<!-- Example Error Code -->
<error>
<code type=”MapUserError”>SystemFailure</code>
<text>Error Text</text>
</error>
4.14 Receiving Atomic Send Routing Info For SM
A client can request to receive a Send Routing Info For SM. This uses a HTTP GET request to receive the request, to respond to the request the HTTP Put request is used
4 Short Message API
40
Figure 20: Receiving a Send Routing Info For SM
HTTP GET
http://192.168.0.1:81/dialogicwebservice/signaling/sriforsm
This will retrieve the first available Send Routing Info For SM, there is no
payload associated with the initial request
The response should include a 200 OK for success. In other cases an appropriate response code will be used as shown in section 3.2.3.
The returned response will have XML payload of the following form:
<?xml version="1.0" encoding="utf-8"?>
<!-- Example SMS received -->
<sriForSm version="1">
<msisdn ton="International" np="ISDN">440044001122</msisdn>
<sessionId>4</sessionId>
</sriForSm>
The Client then should return the response to the Send Routing Info request using a PUT request and specifying the sessionId that the request is associated with.
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/sriforsm/4
If the request is successfully acknowledged then a payload containing the required data shall be included with the HTTP request
The returned response will have XML payload of the following form:
<?xml version="1.0" encoding="utf-8"?>
<!-- Example SMS received -->
<sriForSm version="1">
<imsi>5012423432</imsi>
<msc ton="International" np="ISDN">4400440011342</msc>
<sessionId>4</sessionId?
</sriForSm>
If the request is negatively acknowledged then the payload will contain the
relevant error code
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
41
<?xml version="1.0" encoding="utf-8"?>
<!-- Example Error Code -->
<error>
<code type=”MapUserError”>SystemFailure</code>
<text>Error Text</text>
</error>
4.15 Receiving an Alert Service Centre SWS for alert service centre can be configured in the following options:
MAN - The Client will request alert service centre requests from the
network. If no requests are received then an error is returned to the HLR
AUTO - SWS will automatically send back the successful response to the Alert Service Centre Request from the HLR with no interaction from the user.
ABORT - SWS will automatically abort all Alert Service Centre Requests from the HLR.
The message sequence below shows the Auto mode.
Figure 21: Receiving Alert Service in Auto Mode
The message sequence below shows the Abort mode.
4 Short Message API
42
Figure 22: Receiving Alert Service in Abort Mode
In the Manual Mode the user must request an Alert Service Centre from the HLR using the HTTP GET request. The 200-OK will contain the contains of the Alert Service Centre request received from the HLR and will acknowledge the
Alert Service Centre request back to the HLR. The Manual Mode is shown in the figure below:
Figure 23: Receiving an Alert Service Request in Manual Mode
The response should include a 200 OK for success. In other cases an appropriate response code will be used as shown Section 3.2.3 HTTP Response Codes.
The returned response will have XML payload of the following form:
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
43
<?xml version="1.0" encoding="utf-8"?>
<!-- Example SMS received -->
<alertsc version="1">
<msisdn ton="International" np="ISDN">447777654321</orig>
</alertsc>
5 USSD API
44
5 USSD API
This API allows USSD sessions to be locally initiated or initiated by the mobile device.
URL Method Action
/ussd POST Requests setup of a new application initiated USSD session and send data to the mobile
/ussd GET Receives new ussd session. A session id is returned
/ussd PUT Sends USSD data to mobile without creating a session using a USSD Notify
/ussd/<sessionid> PUT Sends data, response contains user reply
/ussd/<sessionid > GET Receives data
/ussd/<sessionid > DELETE Ends session
5.1 Mobile Initiated Sessions Figure 24: Mobile Originated USSD session below shows a Mobile Originated USSD session:
Client Application SWS Mobile
GET
PUT
PUT + Close Indicator
Process USSD Request
USSD Request
Process USSD Request - Result
USSD Request - Result
200 - OK
204 - No Content
200 - OK
Figure 24: Mobile Originated USSD session
A client requests the next outstanding new mobile initiated session by calling GET on “…/ussd”.
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
45
HTTP GET
http://192.168.0.1:81/dialogicwebservice/signaling/ussd
<?xml version="1.0" encoding="utf-8"?>
<ussd version="1">
<msisdn>447777123456</msisdn>
<alertingPattern>1</alertingPattern>
<ussdString dataCodingScheme="1">Text Here</ussdString>
<sessionId>5544332211</sessionId>
</ussd>
A session id is returned.
Subsequent data sent to that mobile for the same session uses PUT on “…/ussd/<sessionId>”
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/ussd/987654321
The response to the PUT contains the response from the mobile device.
Data can be sent back and forth using further PUT and PUT responses.
The session is ended by using the close indication in the PUT.
A DELETE can be used to force the session to end at any time.
HTTP DELETE
http://192.168.0.1:81/dialogicwebservice/signaling/ussd/987654321
5 USSD API
46
5.2 Client Application Initiated Session The figure below shows an Application Originated USSD session (Figure 25: Application Originated USSD
session):
Client SWS Mobile
PUT
USSD Request
USSD Request
USSD Request - Result201 - Created or 200 - OK
POST
DELETE
END204 - No Content
USSD Request - Result200 - OK
Figure 25: Application Originated USSD session
A client should request the start of a new client application initiated session by calling POST on “…/ussd”.
HTTP POST
http://192.168.0.1:81/dialogicwebservice/signaling/ussd
A session id will be returned together with the response from the mobile device.
Subsequent data sent to that mobile for the same session uses PUT on “…/ussd/<sessionId>”
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
47
The figure below shows an Application Originated USSD session (Figure 26: Application Originated USSD session – with USSD Notify):
:
Client SWS Mobile
PUT (Notify)
USSD Request
USSD Notify
USSD Request - Result201 - Created or 200 - OK
POST
DELETE
END204 - No Content
USSD Notify Response200 - OK
Figure 26: Application Originated USSD session – with USSD Notify
This session is similar to the previous example but is ended by a USSD Notify.
A client requests a Notify by setting a Notify element in the XML payload sent.
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/ussd/<sId>
5.3 Client Application Initiated - USSD Notify A client can request that a USSD Notification be used to send data to a mobile. This uses a HTTP PUT request and similar XML payload to the other USSD APIs. See the Figure 27: Sending a USSD Notify below:
Client SWS Mobile
USSD Notify
USSD Notify Response200 - OK
PUT
5 USSD API
48
Figure 27: Sending a USSD Notify
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/ussd
As a session does not need to be maintained, a session id is not required.
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
49
6 Location and Subscriber Polling API
6.1 Location API All URIs are precluded by the domain and root “/dialogicwebservices/signaling”
URL Method Action
/<msisdn>/location GET Requests location information
Figure 28: Requesting a mobile location below shows a client requesting a mobile location:
Client SWS Mobile
ATI - Request
ATI - Response200 - OK
GET
Figure 28: Requesting a mobile location
A client requests the location of the mobile device by calling GET on “…/<msisdn>/location”.
HTTP GET
http://192.168.0.1:81/dialogicwebservice/signaling/location
The XML payload returned will include the longitude and latitude.
<?xml version="1.0" encoding="utf-8"?>
<!-- -->
<location version="1">
<msisdn ton="International" np="ISDN>447777123456</msisdn>
<latitude>37.56509</latitude>
<longitude>-96.38509</longitude>
</location>
6 Location and Subscriber Polling API
50
6.2 Subscriber State API All URIs are precluded by the domain and root “/dialogicwebservices/signaling”
URL Method Action
/<msisdn>/subscriberstate GET Requests subscriber state information
Figure 29: Requesting a mobile subscriber state below shows a client requesting a mobile subscriber state:
Client SWS Mobile
ATI - Request
ATI - Response200 - OK
GET
Figure 29: Requesting a mobile subscriber state
A client requests the location of the mobile device by calling GET on “…/<msisdn>/subscriberstate”.
HTTP GET
http://192.168.0.1:81/dialogicwebservice/signaling/subscriberstat
e
The XML payload returned will include the current subscriber state
<?xml version="1.0" encoding="utf-8"?>
<!-- -->
<subscriberstate version="1">
<state state="assumedIdle"/>
</subscriberstate>
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
51
6.3 Get IMSI API All URIs are precluded by the domain and root “/dialogicwebservices/signaling”
URL Method Action
/<msisdn>/getimsi GET Requests imsi from the HLR
The figure below shows the Client requesting the IMSI from the HLR using the MSISDN of the mobile (Figure 29: Requesting a mobile subscriber
state
Client SWS HLR
Send IMSI - Request
Send IMSI - Response200 - OK
GET
Figure 30: Requesting the IMSI from the HLR
A client requests the imsi of the mobile device by calling GET on
“…/<msisdn>/getimsi”.
HTTP GET
http://192.168.0.1:81/dialogicwebservice/signaling/44776663213/ge
timsi
The XML payload returned will include the imsi of the mobile station
<?xml version="1.0" encoding="utf-8"?>
<!-- -->
<getimsi version="1">
<imsi>3301231232121</imsi>
</getimsi>
7 Profiles and Multiple Network Support
52
7 Profiles and Multiple Network Support
7.1 Introduction to Profiles Profiles are used across the SWS Web Service API to select specific information required to send network traffic or create criteria for receiving
network requests.
It is possible to have up to 100 profiles in total for all services. The creation of profiles is performed using the Web or Command line MMI.
7.2 Transmit Profiles Profiles allow the user to specify information that will be used in outbound network requests. This information will include the GT address that initiates the request (SCCP calling party number), the network context and specific service information (such as default numbering plans).
The user on creating a request can specify the profile that will be used to generate the network request.
Types of transmit profiles:-
Tx MT-SMS – services using this profile include
o Combined MT-SMS
o Atomic Send Routing Info for SM
o Atomic MT-SMS
o Atomic Report SM Delivery
Tx MO-SMS – services using this profile include
o MO-SMS requests
Ready For SM – services using this profile include
o Ready for SM Requests
USSD– services using this profile include
o USSD
Subscriber - – services using this profile include
o Location Service
o Get Subscriber State
o Get IMSI
HLR Tx – services using this profile include
o Alert Service Centre
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
53
7.3 Receive Profiles Profiles used for the reception of data, the received data from the network must match the criteria specified in the profile for it to match. This
information will normally include the Service Centre Address that the network request was sent to.
When a user requests to receive data matching a profile, only requests that match the requirements will be returned to the user. A user can create profiles that can receive all network requests for a particular service for the same network context or for all network contexts.
If an incoming network requests matches a specific profile completely and also a generalized profile then it can only be received using the specific
profile.
Types of receive profiles:-
Rx MT-SMS – services using this profile include
o Rx Atomic MT-SMS
Tx MO-SMS – services using this profile include
o Rx MO-SMS
o Rx Alert Service Centre
USSD– services using this profile include
o USSD Mobile Initiated
HLR RX – services using this profile include
o Rx Location Request
o Rx Subscriber Request
o Rx Get IMSI
o Rx Send Routing Info for SM
o Rx Report SM Delivery Status
o Rx Ready For SM
8 Parameter Reference
54
8 Parameter Reference
The following sections indicate the parameters used by each service and their respective meanings. The ‘Group’ values in the tables have the following meaning:
Group Meaning
T Top level element structure in XML payload
C Compound XML element with sub-elements
E XML Element
A Attribute of the indicated element
The ‘Req’ and ‘Rsp’ values in the tables have the following meaning:
Req/Rsp Meaning
M Parameter is mandatory
O Parameter is optional
C Parameter is conditionally required. The conditions under which it is needed are indicated.
All of the three services (SMS, Location and USSD) may return error indications stored in an Error XML payload, as defined in section 8.11.
8.1 SMS Service
Parameter Group Req Rsp Details
Sms T M M Top level element for SMS request/responses
Version A O O Attribute of sms
Set to 1
Dest E O n/a Destination Mobile Subscriber ISDN Number
Identifies the mobile number of the device that the SMS is to be sent.
Ton A O O Attribute of dest
Type of number
Npi A O O Attribute of dest
Numbering Plan Indicator
Imsi E n/a M International Mobile Subscriber Identity
The IMSI Is a unique identifier of the SIM in the mobile device.
Message E O C1 UTF-8 Encoded text string
Orig E O O Origination Mobile Subscriber ISDN Number
Identifies the mobile number of the device from which the SMS is sent from.
Ton A O O Attribute of orig
Type of number
Npi A O O Attribute of orig
Numbering Plan Indicator
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
55
sessionId E M for existing session
O Identifies the sms session being handled. This is returned in the first response to a GET or PUT where multiple concatenated messages are required to be sent or received
smsDeliver E C1 O Compound parameter with sub-elements shown in section 8.1.1 SMS
Deliver parameters.
This used to specify SMS messages which cannot be supported by the simple message format, for example binary or concatenated messages.
Note 1 - Either message or smsDeliver should be present
8.1.1 SMS Deliver parameters
Parameter Group Req Rsp Details
mms E M M TP-MMS flag as specified in 23.040
Boolean, true means more messages are to send.
rp E M M TP-RP flag as specified in 23.040
Boolean, true means Reply path exists
udhi E M M TP-UDHI flag as specified in 23.040
Boolean, true means TP-UD contains a header
sri E M M TP-SRI flag as specified in 23.040
Boolean, true means a status report is requested
pid E M M TP-PID as specified in 23.040
Protocol Identifier
Value between 0..255 representing the protocol used.
dcs E M M TP-DCS as specified in 23.040
Data coding scheme
Value between 0..255 representing the protocol used.
scts E M M TP-SCTS as specified in 23.040
This is the service centre time stamp encoded as Base64.
udl E M M TP-UDL as specified in 23.040
This is the length of the unit data parameter specified in
If the ud parameter is encoded in GSM 7-bit default alphabet then this represents the number of septets used.
If the ud parameter is encoded in GSM 7-bit default alphabet AND the udhi is set the then this represents the number of septets used in the user data header plus the user data field.
If the ud parameter is encoded using 8-bit data then the udl should indicate the number of octets used.
If the ud parameter is encoded using 8-bit data and the udhi is set then the udl should indicate the number of octets used in the header plus the user data field.
ud E M M TP-UD as specified in 23.040
Contains the SMS user data encoded as Base64
8 Parameter Reference
56
8.2 Atomic SMS-MT Service
Parameter Group Req Rsp Details
smsmt T M M Top level element for SMS-MT request/responses
version A O O Attribute of sms
Set to 1
msc E O n/a Mobile Switching Centre ISDN Number
Identifies the MSC that the destination mobile is currently located on.
yon A O O Attribute of msc
Type of number
npi A O O Attribute of msc
Numbering Plan Indicator
imsi E n/a M International Mobile Subscriber Identity
The IMSI Is a unique identifier of the SIM in the mobile device.
Message E O C1 UTF-8 Encoded text string
Orig E O O Origination Mobile Subscriber ISDN Number
Identifies the mobile number of the device from which the SMS is sent from.
Ton A O O Attribute of orig
Type of number
Npi A O O Attribute oforig
Numbering Plan Indicator
sessionId E M for existing session
O Identifies the sms session being handled. This is returned in the first response to a GET or PUT where multiple concatenated messages are required to be sent or received
smsDeliver E C1 O Compound parameter with sub-elements shown in section 8.1.1 SMS
Deliver parameters.
This used to specify SMS messages which cannot be supported by the simple message format, for example binary or concatenated messages.
Note 1 - Either message or smsDeliver should be present
8.3 MO-SMS Service
Parameter Group Req Rsp Details
SmsMo T M M Top level element for SMS-MO request/responses
Version A O O Attribute of sms
Set to 1
Dest E O M Destination Mobile Subscriber ISDN Number
Identifies the destination mobile address for the SMS
Ton A O O Attribute of dest
Type of number
Npi A O O Attribute of dest
Numbering Plan Indicator
orig E O M Origination Mobile Subscriber ISDN Number
Identifies the originating mobile address of the SMS
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
57
ton A O O Attribute of orig
Type of number
npi A O O Attribute of orig
Numbering Plan Indicator
destSrvCtr E M O SMS Service Centre that SMS is to be sent to
ton A O O Attribute of destSrvCtr
Type of number
npi A O O Attribute of destSrvCtr
Numbering Plan Indicator
Msc E M O MSC ISDN Number
The MSC Address that the SMS-MO originated from
ton A O O Attribute of msc
Type of number
npi A O O Attribute of msc
Numbering Plan Indicator
smsSubmit E C1 O Compound parameter with sub-elements shown in section 8.3.1 SMS
Submit parameters.
This used to specify SMS messages which cannot be supported by the simple message format, for example binary or concatenated messages.
Note 1 - Either message or smsDeliver should be present
8.3.1 SMS Submit parameters
Parameter Group Req Rsp Details
rd E M M TP-Reject-Duplicates flag as specified in 23.040
Boolean, true means reject duplicates is set.
rp E M M TP-RP flag as specified in 23.040
Boolean, true means Reply path exists
udhi E M M TP-UDHI flag as specified in 23.040
Boolean, true means TP-UD contains a header
srr E M M TP-Status-Report-Request flag as specified in 23.040
Boolean, true means a status report is requested
pid E M M TP-PID as specified in 23.040
Protocol Identifier
Value between 0..255 representing the protocol used.
dcs E M M TP-DCS as specified in 23.040
Data coding scheme
Value between 0..255 representing the protocol used.
mr E M M TP-Message-Reference as specified in 23.040
Value between 0.255
vpRel E O O TP-Validity-Period (Relative Format) as specified in 23.040
Value between 0.255
vpAbs E O O TP-Validity-Period (Absolute Format) as specified in 23.040
Base 64 encoded.
8 Parameter Reference
58
vpEnc E O O TP-Validity-Period (Absolute Format) as specified in 23.040
Base 64 encoded.
udl E M M TP-UDL as specified in 23.040
This is the length of the unit data parameter specified in
If the ud parameter is encoded in GSM 7-bit default alphabet then this represents the number of septets used.
If the ud parameter is encoded in GSM 7-bit default alphabet AND the udhi is set the then this represents the number of septets used in the user data header plus the user data field.
If the ud parameter is encoded using 8-bit data then the udl should indicate the number of octets used.
If the ud parameter is encoded using 8-bit data and the udhi is set then the udl should indicate the number of octets used in the header plus the user data field.
ud E M M TP-UD as specified in 23.040
Contains the SMS user data encoded as Base64
8.4 Alert Service Centre Service
Parameter Group Req Rsp Details
AlertSC T M M Top level element for AlertSC request/responses
Version A O O Attribute of sms
Set to 1
msisdn E n/a M Mobile Subscriber ISDN Number
Identifies the mobile address received in the alert Service Centre
ton A n/a O Attribute of msisdn
Type of number
npi A n/a O Attribute of msisdn
Numbering Plan Indicator
8.5 Send Routing Info For SM Service
Parameter Group Req Rsp Details
AlertSC T M M Top level element for Send Routing Info For SM request/responses
Version A O O Attribute of sriForSm
Set to 1
msisdn E M n/a Mobile Subscriber ISDN Number
Identifies the mobile address that the routing information is required for
ton A O n/a Attribute of msisdn
Type of number
npi A O n/a Attribute of msisdn
Numbering Plan Indicator
SmRpPri E O n/a Indicates whether SMS delivery will be attempted even when a service centre address is contained in the Message Waiting Data file in the HLR
Specified in 29.002.
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
59
gprsSupportIndicator E O n/a If the SMS-GMSC supports of receiving two numbers for HLR
Specified in 29.002
For future expansion
smRpMti E O n/a RP-Message Type Indicator of the Short Message
Specified in 29.002
smRpSmea E O n/a Originating SME-Address of the Short Message Entity
Specified in 29.002
ton A O n/a Attribute of smRpSmea
Type of number
npi A O n/a Attribute of smRpSmea
Numbering Plan Indicator
smDeliveryNotIntended E O n/a This parameter indicates whether the delivery of a short message is not intended.
Specified in 29.002
msc E n/a M Mobile Switching Centre ISDN Number
MSC address that the terminating mobile is located at
ton A n/a M Attribute of smRpSmea
Type of number
npi A n/a M Attribute of smRpSmea
Numbering Plan Indicator
imsi E n/a O International Mobile Subscriber Identity
The IMSI Is a unique identifier of the SIM in the mobile device.
lmsi E n/a O Mobile local identity specified by residing VLR
gprsNodeIndicator E n/a O Present if SGSN is the primary location of the mobile.
Reserved for future expansion
sgsnNum E n/a O SGSN Address for GPRS Mobiles.
Reserved for future expansion
ton A n/a M Attribute of sgsnNum
Type of number
npi A n/a M Attribute of sgsnNum
Numbering Plan Indicator
informSC E n/a O Compound parameter with sub-elements shown in section 8.5.1 Inform Service Centre parameters.
This used to specify contents received in the optional Inform Service Centre.
8.5.1 Inform Service Centre parameters
Parameter Group Req Rsp Details
storedMsisdn E n/a O MSISDN stored in the HLR of the requested mobile
ton A n/a M Attribute of storedMsisdn
Type of number
npi A n/a M Attribute of storedMsisdn
Numbering Plan Indicator
8 Parameter Reference
60
mnrf E n/a O Mobile Station Not Reachable flag if present
mcef E n/a O Memory Capacity Exceeded flag if present
mnrg E n/a O Mobile Station Not Reachable for GPRS flag if present
Reserved for future expansion
srvCtrSetInHlr E n/a O Service Centre already set in the HLR
absentSubDiagSm E n/a O The reason that the subscriber is absent
Values specified 23.040
addAbsentSubDiagSm E n/a O The reason that the subscriber is absent for GPRS
Values specified 23.040
Reserved for future expansion
8.6 Report SM Delivery Status Service
Parameter Group Req Rsp Details
reportSMDeliver T M M Top level element for Report SM Delivery request/responses
bersion A O O Attribute of sms
Set to 1
msisdn E M n/a Mobile Subscriber ISDN Number
Identifies the mobile address received in the alert Service Centre
ton A O n/a Attribute of msisdn
Type of number
npi A O n/a Attribute of msisdn
Numbering Plan Indicator
deliveryOutcome E M n/a Indicates the status of the mobile terminated SM delivery
absentSubDiagSm E O n/a Absent subscriber Diagnostic
Values specified 23.040
gprsSupportInd E O n/a GPRS Support Ind, SMS-GMSC supports handling of two delivery Outcomes
gprsDeliveryOutcome E O n/a Indicates the status of the mobile terminated SM delivery for GPRS
gprsAbsentSubDiagSm E O n/a Absent subscriber Diagnostic for GPRS
Values specified 23.040
imsSupportInd E O n/a IMS Support Ind, SMS-GMSC supports handling of two delivery Outcomes
imsDeliveryOutcome E O n/a Indicates the status of the mobile terminated SM delivery for IMS
imsAbsentSubDiagSm E O n/a Absent subscriber Diagnostic for IMS
Values specified 23.040
storedMsisdn E n/a O MSISDN stored in the HLR of the requested mobile
Ton A n/a O Attribute of storedMsisdn
Type of number
Npi A n/a O Attribute of storedMsisdn
Numbering Plan Indicator
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
61
8.7 USSD Service
Parameter Group Req Rsp Details
Ussd T M M Top level element for USSD request/responses
Version A O O Attribute of ussd
Set to 1
alertingPattern E O O Optional parameter to set a network specific alerting indication. Values are a single character representing a single byte value.
Close E C2 C
2 Set element to indicate a request to close session. For example, in a
PUT request, that should close the session on completion.
This prevents the need for an unnecessary DELETE request.
Msisdn E M for new session
M for new session
Mobile Subscriber ISDN Number
Identifies the mobile number of the device being located.
Ton A O M Attribute of msisdn
Type of Number
Npi A O M Attribute of msisdn
Numbering Plan Indicator
sessionId E O M for existing session
Identifies the ussd session being handled. Typically this is returned in the first response to a GET on /ussd.
Timeout E n/a n/a For future use.
ussdString E M M3 Represents the text send or received in a USSD message
Imsi E n/a C4 International Mobile Subscriber Identity
The IMSI Is a unique identifier of the SIM in the mobile device.
dataCodingScheme A O O USSD coding scheme to be used as defined in the CBD Data Scheme in 3GPP 23.038.
Values supported:
0-15 – Default Alphabet with Language
16,17 – Default Alphabet/UCS2
64, 65, 66 – General Data Coding
Notify E O O Sends a USSD Notify to the network instead of a USSD Request
Note 2 – Required to request a session to be closed after processing action. Will be present in responses to indicate session has been closed.
Note 3 – Passed up if available.
Note 4 – If a USSD-REQ or USSD-NOT is requested from the API is the first message in a session and the ussdString is greater than 166 characters then the SWS send two messages. The first will perform the dialogue initiation
before transmitting the USSD string in a later message. This is to permit the longer string to fit into an MSU size limit of 272 characters allowing for the GT
addresses (including MSISDN) are of the maximum size.
8 Parameter Reference
62
8.8 Location Service
Parameter Group Req Rsp Details
location T M M Top level element for location responses
version A n/a O Attribute of location
Set to 1
latitude E n/a O Location latitude position in real valued degrees (-180 to +180)
longitude E n/a O Location longitude position in real valued degrees (-90 to +90)
msisdn E n/a O Mobile Subscriber ISDN Number
Identifies the mobile number of the device being located.
ton A n/a O Attribute of msisdn
Type of Number
npi A n/a O Attribute of msisdn
Numbering Plan Indicator
cellId C n/a O Cell Id of the location
geodeticinformation C n/a O Location returned in the geodetic format
geographicalinfomationgprs C n/a O Location returned in the geographical format for a GPRS enabled phone
geographicalinformation C n/a O Location returned in the geographical format
8.8.1 Cell Id Parameters
Parameter Group Req Rsp Details
mcc
E M n/a Mobile Country Code as specified in 29.002 section 17.7.8
mnc E M n/a Mobile Network Code as specified in 29.002 section 17.7.8
lac E M n/a Location Area Code as specified in 29.002 section 17.7.8
ci E O n/a Cell Identity as specified in 29.002 section 17.7.8
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
63
8.9 Subscriber State Service
Parameter Group Req Rsp Details
SubscriberState T M M Top level element for location responses
Version A n/a O Attribute of location
Set to 1
Msisdn E M n/a Mobile Subscriber ISDN Number
Identifies the mobile number of the device being located.
State E n/a M Subscriber State of the Mobile Subscriber
state A n/a M Subscriber state
Not Reachable E n/a O Not reachable reason for the mobile subscriber
8 Parameter Reference
64
8.10 Get IMSI Service
Parameter Group Req Rsp Details
GetImsi T M M Top level element for Get IMSI responses
Version A n/a O Attribute of location
Set to 1
Msisdn E M n/a Mobile Subscriber ISDN Number
Identifies the mobile number of the device being located.
Imsi E n/a M International Mobile Subscriber Identity
The IMSI Is a unique identifier of the SIM in the mobile device.
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
65
8.11 Error
Parameter Group Rsp Details
error T M Top level element for error information
Contains details of error
code A M Error code
type A M Attribute of the error
code, defines the
group of error codes
(e.g. MAP User Error
or Internal System
Error
text E M Contains details of error
8.11.1 Error Code Types
Error Code Types
internalFailure
mapUserError
userError
mapProviderError
noDataWaiting
absMandParam
invalidSession
invalidParamLen
servNotSupported
sessionTerminated
localTimeout
parseError
8.11.2 Error Code Type – internalFailureCodeType
Error Code
noResources
invalidGCTFmt
insufficientRpnd
8.11.3 Error Code Type – mapErrorCodeType
Error Code
unknownSubscriber
8 Parameter Reference
66
unknownMSC
unidentifiedSubscriber
absentSubscriberSM
unknownEquipment
roamingNotAllowed
illegalSubscriber
bearerServiceNotProvisioned
teleServiceNotProvisioned
illegalEquipment
callBarred
forwardingViolation
cugReject
illegalSSOperation
ssErrorStatus
ssNotAvailable
ssSubscriptionViolation
ssIncompatibility
facilityNotSupported
ongoingGroupCall
noHandoverNumberAvailable
subsequentHandoverFailure
absentSubscriber
incompatibleTerminal
shortTermDenial
longTermDenial
subscriberBusyForMTSMS
smDeliveryFailure
messageWaitingListFull
systemFailure
dataMissing
unexpectedDataValue
pwRegistrationFailure
negativePWCheck
noRoamingNumberAvailable
tracingBufferFull
targetCellOutsideGroupCallArea
numberOfPWAttemptsViolation
numberChanged
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
67
busySubscriber
noSubscriberReply
forwardingFailed
orNotAllowed
atiNotAllowed
noGroupCallNumberAvailable
resourceLimitation
unauthorizedRequestingNetwork
unauthorizedLCSClient
positionMethodFailure
unknownOrUnreachableLCSClient
mmEventNotSupported
atsiNotAllowed
atmNotAllowed
informationNotAvailable
unknownAlphabet
ussdBusy
Unknown
8.11.4 Error Code Type – userErrorCodeType
Error Code
appIdAbsent
appIdInvalid
appNotActive
invalidState
8.11.5 Error Code Type – providerErrorCodeType
Error Code
appIdAbsent
appIdInvalid
appNotActive
invalidState
8.11.6 MAP User Errors
Error Code
Unknown Subscriber
Unknown MSC
8 Parameter Reference
68
Error Code
Unidentified Subscriber
Absent Subscriber SM
Unknown Equipment
Roaming Not Allowed
Illegal Subscriber
Bearer Service Not Provisioned
Teleservice Not Provisioned
Illegal Equipment
Call Barred
Forwarding Violation
CUG_Reject
Illegal SS Operation
SS Error Status
SS Not Available
SS Subscription Violation
SS Incompatibility
Facility Not Supported
PW Registration Failure
Negative PW Check
NO Handover Number Available
Subsequent Handover Failure
Absent Subscriber
Subscriber Busy for MT SMS
SM Delivery Failure
message_waiting_list_full
system_failure
data_missing
unexpected_data_value
resource_limitation
initiating_release
no_roaming_number_available
tracing_buffer_full
number_of_pw_attempts_violation
number_changed
busy_subscriber
no_subscriber_reply
forwarding_failed
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
69
Error Code
or_not_allowed
ATI_not_allowed
unauthorised_requesting_network
unauthorised_LCS_client
position_method_failure
unknown_or_unreachable_LCS_client
mm_event_not_supported
atsi_not_allowed
atm_not_allowed
information_not_available
unknown_alphabet
ussd_busy
9 Application Development Guidelines
70
9 Application Development Guidelines
9.1 Application Development Frameworks The web-services APIs make use of HTTP with XML payloads and are constructed to follow RESTful principals. This allows many different
development environments and frameworks to be used.
The following environments have been used to create the example applications:
Language Development Environment
Java NetBeans 6.9 IDE
C# Microsoft Visual Studio 2005
PHP Various
Other development environments are available and should provide facilities
suitable for use with the SWS APIs.
9.2 XML Handling In order to support auto-generated handling and validation of XML,
supporting XSD schema files are provided (See Appendix A.1). This schema can be used with supporting XML handling libraries such as JAXB in Java.
9.3 HTTP/HTTPS The URIs and port numbers used in this document assume use of HTTP for
the RESTful interface running at the default port number of 81. The port numbers for HTTP and HTTPS are configurable. Please verify that the correct values are being used on the specific system.
A secure API connection to the SWS system can be created by enabling SSL. This will mean a corresponding change to the URIs and Port numbers used. When enabled, the default port for the RESTful interface over HTTPS is 442.
The method by which SSL/HTTPS is enabled and certificates accepted is system and platform dependent.
9.4 Use of Expect: HTTP 100 – Continue The SWS platform does not respond to requests requiring HTTP 100 – Continue responses. The default behavior of some web-service frameworks (e.g. C#/.NET) may be to expect the 100 – Continue response.
The use of the HTTP 100 – Continue is inefficient and inappropriate for the
APIs being used. This should be disabled for correct behavior. For example:
HttpWebRequest request = WebRequest.Create(uri) as HttpWebRequest;
request.ServicePoint.Expect100Continue = false;
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
71
10 Application Examples
A number of example applications are available for different environments to show different aspects of the system and provide different sets of test functionality.
10.1 Java SWS Test Utility The SMS test sender application makes use of the ‘Jersey’ API support for RESTful web-services in Java. It also makes use of the JAXB support for conversion of data to and from XML based on the supplied XSD schema files.
The user interface makes use of the Swing framework (Figure 31: Java SMS
Test Sender).
Figure 31: Java SMS Test Sender
The application can be used by entering the server IP address, destination number and message to send. The ‘Advanced‘ tab allows the encoding scheme, type of number and numbering plan identifier settings to be changed
if necessary.
10 Application Examples
72
10.2 C# SWS Example Application This application makes use of a simple GUI and C# components to allow testing of the API with an SWS server and is shown in Figure 32: C# Test
Sender.
Figure 32: C# Test Sender
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
73
10.3 PHP Example A simple application written in PHP. It gives an example of a scripted language and is shown below in Figure 33: PHP Test Sender.
Figure 33: PHP Test Sender
XSD Files
74
Appendix A. XSD Files
A.1 SWS XSD Schema
<?xml version="1.0" encoding="utf-8" ?>
<!--Copyright (C) 2010-2013 Dialogic Corporation. All rights reserved. -->
<!--SWS XSD Version 1.2.3 30-Jan-13 -->
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="versionType">
<xs:restriction base="xs:int">
<xs:minInclusive value="1" />
<xs:maxInclusive value="1" />
</xs:restriction>
</xs:simpleType>
<xs:complexType name="ussdType">
<xs:sequence>
<xs:element minOccurs="0" name="msisdn" type="addressFieldType" />
<xs:element minOccurs="0" name="imsi" type="xs:normalizedString" />
<xs:element minOccurs="0" name="timeout">
<xs:simpleType>
<xs:restriction base="xs:int">
<xs:minInclusive value="0" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element minOccurs="0" name="alertingPattern">
<xs:simpleType>
<xs:restriction base="xs:short">
<xs:minInclusive value="0" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element minOccurs="0" name="ussdString">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="dataCodingScheme" type="xs:unsignedByte" />
<xs:attribute name="language" type="xs:language" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="sessionId" type="xs:normalizedString" />
<xs:element minOccurs="0" name="notify" />
<xs:element minOccurs="0" name="close" />
<xs:element minOccurs="0" name="testProcessUssdReq" />
<xs:element name="optionalInfo" type="oiType" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="smsType">
<xs:sequence>
<xs:element minOccurs="0" name="dest" type="addressFieldType" />
<xs:element minOccurs="0" name="orig" type="addressFieldType" />
<xs:element minOccurs="0" name="imsi" type="xs:normalizedString" />
<xs:element minOccurs="0" name="message">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string" />
</xs:simpleContent>
</xs:complexType>
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
75
</xs:element>
<xs:element minOccurs="0" name="sessionId" type="xs:normalizedString" />
<xs:element name="smsDeliver" type="tpType" />
<xs:element minOccurs="0" name="reportSmDeliveryStatus" type="xs:boolean"/>
<xs:element minOccurs="0" name="reportSmDeliveryStatusGprs" type="xs:boolean"/>
<xs:element name="optionalInfo" type="oiType" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="locationServiceType">
<xs:sequence>
<xs:element minOccurs="0" name="msisdn" type="addressFieldType" />
<xs:element minOccurs="0" maxOccurs="1" name="longitude" type="longitudeType"
/>
<xs:element minOccurs="0" maxOccurs="1" name="latitude" type="latitudeType" />
<xs:element minOccurs="0" maxOccurs="1" name="cellId" type="cellIdType" />
<xs:element minOccurs="0" maxOccurs="1" name="geographicalInformation"
type="geographicalInformationType" />
<xs:element minOccurs="0" maxOccurs="1" name="geodeticInformation"
type="geodeticInformationType" />
<xs:element minOccurs="0" maxOccurs="1" name="geographicalInfomationGPRS"
type="geographicalInformationType" />
<xs:element minOccurs="0" name="sessionId" type="xs:normalizedString" />
<xs:element name="optionalInfo" type="oiType" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="smsMoType">
<xs:sequence>
<xs:element minOccurs="0" name="dest" type="addressFieldType" />
<xs:element minOccurs="0" name="orig" type="addressFieldType" />
<xs:element minOccurs="0" name="destSrvCtr" type="addressFieldType" />
<xs:element minOccurs="0" name="msc" type="addressFieldType" />
<xs:element name="smsSubmit" type="moTpType" />
<xs:element name="optionalInfo" type="oiType" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="alertSCType">
<xs:sequence>
<xs:element minOccurs="1" name="msisdn" type="addressFieldType" />
<xs:element minOccurs="0" name="destSrvCtr" type="addressFieldType" />
<xs:element name="optionalInfo" type="oiType" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="readyForSMType">
<xs:sequence>
<xs:element minOccurs="0" name="noteSubPresent" type="xs:unsignedByte"/>
<xs:element minOccurs="1" name="imsi" type="xs:normalizedString" />
<xs:element minOccurs="1" name="hlrAddr" type="addressFieldType" />
<xs:element minOccurs="0" name="alertReason" type="alertReasonType" />
<xs:element minOccurs="0" name="alertReasonInd" />
<xs:element minOccurs="0" name="additionalAlertReasonInd" />
<xs:element minOccurs="0" name="sessionId" type="xs:normalizedString" />
<xs:element name="optionalInfo" type="oiType" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="sriForSmType">
<xs:sequence>
<xs:element minOccurs="1" name="msisdn" type="addressFieldType" />
<xs:element minOccurs="0" name="smRpPri" type="xs:boolean" />
<xs:element minOccurs="0" name="gprsSupportInd"/>
<xs:element minOccurs="0" name="smRpMti" type="smRpMtiType" />
<xs:element minOccurs="0" name="smRpSmea" type="addressFieldType" />
<xs:element minOccurs="0" name="smDeliveryNotIntended"
type="smDeliveryNotIntendedType"/>
<xs:element minOccurs="0" name="msc" type="addressFieldType" />
<xs:element minOccurs="0" name="imsi" type="xs:normalizedString" />
XSD Files
76
<xs:element minOccurs="0" name="lmsi" type="xs:normalizedString" />
<xs:element minOccurs="0" name="gprsNodeIndicator"/>
<xs:element minOccurs="0" name="sgsnNum" type="addressFieldType" />
<xs:element minOccurs="0" maxOccurs="1" name="informSc" type="informScType"/>
<xs:element minOccurs="0" name="sessionId" type="xs:normalizedString" />
<xs:element name="optionalInfo" type="oiType" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="smsMtType">
<xs:sequence>
<xs:element minOccurs="1" name="msc" type="addressFieldType" />
<xs:element minOccurs="0" name="orig" type="addressFieldType" />
<xs:element minOccurs="1" name="imsi" type="xs:normalizedString" />
<xs:element minOccurs="0" name="message">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string" />
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="sessionId" type="xs:normalizedString" />
<xs:element name="smsDeliver" type="tpType" />
<xs:element name="optionalInfo" type="oiType" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="reportSMDeliverType">
<xs:sequence>
<xs:element minOccurs="1" name="msisdn" type="addressFieldType" />
<xs:element minOccurs="1" name="deliveryOutcome" type="smDeliveryOutcomeType"
/>
<xs:element minOccurs="0" name="absentSubDiagSm" type="absentSubDiagSmType" />
<xs:element minOccurs="0" name="gprsSupportInd" />
<xs:element minOccurs="0" name="gprsDeliveryOutcomeInd" />
<xs:element minOccurs="0" name="gprsDeliveryOutcome"
type="smDeliveryOutcomeType" />
<xs:element minOccurs="0" name="gprsAbsentSubDiagSm" type="absentSubDiagSmType"
/>
<xs:element minOccurs="0" name="imsInd" />
<xs:element minOccurs="0" name="imsDeliveryOutcome"
type="smDeliveryOutcomeType" />
<xs:element minOccurs="0" name="imsAbsentSubDiagSm" type="absentSubDiagSmType"
/>
<xs:element minOccurs="0" name="storedMsisdn" type="addressFieldType" />
<xs:element minOccurs="0" name="sessionId" type="xs:normalizedString" />
<xs:element name="optionalInfo" type="oiType" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="subscriberStateServiceType">
<xs:sequence>
<xs:element minOccurs="0" name="state" type="subscriberStateType"/>
<xs:element minOccurs="0" name="msisdn" type="addressFieldType" />
<xs:element minOccurs="0" name="sessionId" type="xs:normalizedString" />
<xs:element minOccurs="0" name="optionalInfo" type="oiType" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="getImsiServiceType">
<xs:sequence>
<xs:element minOccurs="0" name="msisdn" type="addressFieldType" />
<xs:element minOccurs="0" name="imsi" type="xs:normalizedString" />
<xs:element minOccurs="0" name="sessionId" type="xs:normalizedString" />
<xs:element minOccurs="0" name="optionalInfo" type="oiType" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="anytimeInterrogationServiceType">
<xs:sequence>
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
77
<xs:element minOccurs="0" name="msisdn" type="addressFieldType" />
<xs:element minOccurs="0" name="imsi" type="xs:normalizedString" />
<xs:element minOccurs="0" name="hlrAddr" type="addressFieldType" />
<xs:element minOccurs="0" name="locationReq">
<xs:complexType>
<xs:attribute name="currentLocation" type="xs:boolean" />
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="subscriberStateReq"/>
<xs:element minOccurs="0" name="requestedDomain" type="requestedDomainType"/>
<xs:element minOccurs="0" name="imeiReq"/>
<xs:element minOccurs="0" name="msClassMarkReq"/>
<xs:element minOccurs="0" name="mnpRequestedInfo"/>
<xs:element minOccurs="0" name="tAdsData"/>
<xs:element minOccurs="0" name="requestedNodes" type="requestedNodesType"/>
<xs:element minOccurs="0" name="locationRsp" type="locationRspType"/>
<xs:element minOccurs="0" name="subscriberStateRsp"
type="subscriberStateType"/>
<xs:element minOccurs="0" name="psSubscriberStateRsp"
type="psSubscriberStateType"/>
<xs:element minOccurs="0" name="gprsMsClass" type="gprsMsClassType"/>
<xs:element minOccurs="0" name="imeiRsp" type="xs:normalizedString"/>
<xs:element minOccurs="0" name="msClassMarkRsp" type="xs:normalizedString"/>
<xs:element minOccurs="0" name="mnpInfoRes" type="mnpInfoResType"/>
<xs:element minOccurs="0" name="imsVoiceOverPsSessionsIndication"
type="imsVoiceOverPsSessionsIndicationType"/>
<xs:element minOccurs="0" name="lastUeActivityTime"
type="xs:normalizedString"/>
<xs:element minOccurs="0" name="lastRatType" type="UsedRatTypeType"/>
<xs:element minOccurs="0" name="sessionId" type="xs:normalizedString"/>
<xs:element minOccurs="0" name="optionalInfo" type="oiType" />
<xs:element minOccurs="0" name="epsSubscriberStateRsp"
type="psSubscriberStateType"/>
</xs:sequence>
</xs:complexType>
<xs:element name="sms">
<xs:complexType>
<xs:complexContent mixed="false">
<xs:extension base="smsType">
<xs:attribute name="version" type="versionType" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="error">
<xs:complexType>
<xs:complexContent mixed="false">
<xs:extension base="errorType">
<xs:attribute name="version" type="versionType" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="ussd">
<xs:complexType>
<xs:complexContent mixed="false">
<xs:extension base="ussdType">
<xs:attribute name="version" type="versionType" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="smsmo">
<xs:complexType>
<xs:complexContent mixed="false">
XSD Files
78
<xs:extension base="smsMoType">
<xs:attribute name="version" type="versionType" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="location">
<xs:complexType>
<xs:complexContent mixed="false">
<xs:extension base="locationServiceType">
<xs:attribute name="version" type="versionType" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="alertSC">
<xs:complexType>
<xs:complexContent mixed="false">
<xs:extension base="alertSCType">
<xs:attribute name="version" type="versionType" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="sriForSm">
<xs:complexType>
<xs:complexContent mixed="false">
<xs:extension base="sriForSmType">
<xs:attribute name="version" type="versionType" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="smsmt">
<xs:complexType>
<xs:complexContent mixed="false">
<xs:extension base="smsMtType">
<xs:attribute name="version" type="versionType" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="reportSMDeliver">
<xs:complexType>
<xs:complexContent mixed="false">
<xs:extension base="reportSMDeliverType">
<xs:attribute name="version" type="versionType" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="readyForSM">
<xs:complexType>
<xs:complexContent mixed="false">
<xs:extension base="readyForSMType">
<xs:attribute name="version" type="versionType" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="subscriberState">
<xs:complexType>
<xs:complexContent mixed="false">
<xs:extension base="subscriberStateServiceType">
<xs:attribute name="version" type="versionType"/>
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
79
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="anytimeInterrogation">
<xs:complexType>
<xs:complexContent mixed="false">
<xs:extension base="anytimeInterrogationServiceType">
<xs:attribute name="version" type="versionType"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="getImsi">
<xs:complexType>
<xs:complexContent mixed="false">
<xs:extension base="getImsiServiceType">
<xs:attribute name="version" type="versionType"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:complexType name="errorType">
<xs:sequence>
<xs:element minOccurs="1" name="code" type="errorCode"/>
<xs:element minOccurs="1" name="text" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="errorCode">
<xs:choice maxOccurs="1">
<xs:element name="internalFailureCode" type="internalFailureCodeType"/>
<xs:element name="mapErrorCode" type="mapErrorCodeType"/>
<xs:element name="userErrorCode" type="userErrorCodeType"/>
<xs:element name="providerErrorCode" type="providerErrorCodeType"/>
<xs:element name="absMandParamCode" type="parameterType"/>
<xs:element name="invalidSessionCode" type="xs:normalizedString"/>
<xs:element name="invalidParamLenCode" type="parameterType"/>
<xs:element name="serviceNotSupportedCode" type="serviceType"/>
<xs:element name="sessionTerminated" type="sessionTerminatedType"/>
</xs:choice>
<xs:attribute name="type">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="internalFailure"/>
<xs:enumeration value="mapUserError"/>
<xs:enumeration value="userError"/>
<xs:enumeration value="mapProviderError"/>
<xs:enumeration value="noDataWaiting"/>
<xs:enumeration value="absMandParam"/>
<xs:enumeration value="invalidSession"/>
<xs:enumeration value="invalidParamLen"/>
<xs:enumeration value="servNotSupported"/>
<xs:enumeration value="sessionTerminated"/>
<xs:enumeration value="localTimeout"/>
<xs:enumeration value="parseError"/>
<xs:enumeration value="invalidProfile"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:simpleType name="internalFailureCodeType">
<xs:restriction base="xs:string">
<xs:enumeration value="noResources"/>
<xs:enumeration value="invalidGCTFmt"/>
<xs:enumeration value="insufficientRpnd"/>
XSD Files
80
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="mapErrorCodeType">
<xs:restriction base="xs:string">
<xs:enumeration value="unknownSubscriber"/>
<xs:enumeration value="unknownMSC"/>
<xs:enumeration value="unidentifiedSubscriber"/>
<xs:enumeration value="absentSubscriberSM"/>
<xs:enumeration value="unknownEquipment"/>
<xs:enumeration value="roamingNotAllowed"/>
<xs:enumeration value="illegalSubscriber"/>
<xs:enumeration value="bearerServiceNotProvisioned"/>
<xs:enumeration value="teleServiceNotProvisioned"/>
<xs:enumeration value="illegalEquipment"/>
<xs:enumeration value="callBarred"/>
<xs:enumeration value="forwardingViolation"/>
<xs:enumeration value="cugReject"/>
<xs:enumeration value="illegalSSOperation"/>
<xs:enumeration value="ssErrorStatus"/>
<xs:enumeration value="ssNotAvailable"/>
<xs:enumeration value="ssSubscriptionViolation"/>
<xs:enumeration value="ssIncompatibility"/>
<xs:enumeration value="facilityNotSupported"/>
<xs:enumeration value="ongoingGroupCall"/>
<xs:enumeration value="noHandoverNumberAvailable"/>
<xs:enumeration value="subsequentHandoverFailure"/>
<xs:enumeration value="absentSubscriber"/>
<xs:enumeration value="incompatibleTerminal"/>
<xs:enumeration value="shortTermDenial"/>
<xs:enumeration value="longTermDenial"/>
<xs:enumeration value="subscriberBusyForMTSMS"/>
<xs:enumeration value="smDeliveryFailure"/>
<xs:enumeration value="messageWaitingListFull"/>
<xs:enumeration value="systemFailure"/>
<xs:enumeration value="dataMissing"/>
<xs:enumeration value="unexpectedDataValue"/>
<xs:enumeration value="pwRegistrationFailure"/>
<xs:enumeration value="negativePWCheck"/>
<xs:enumeration value="noRoamingNumberAvailable"/>
<xs:enumeration value="tracingBufferFull"/>
<xs:enumeration value="targetCellOutsideGroupCallArea"/>
<xs:enumeration value="numberOfPWAttemptsViolation"/>
<xs:enumeration value="numberChanged"/>
<xs:enumeration value="busySubscriber"/>
<xs:enumeration value="noSubscriberReply"/>
<xs:enumeration value="forwardingFailed"/>
<xs:enumeration value="orNotAllowed"/>
<xs:enumeration value="atiNotAllowed"/>
<xs:enumeration value="noGroupCallNumberAvailable"/>
<xs:enumeration value="resourceLimitation"/>
<xs:enumeration value="unauthorizedRequestingNetwork"/>
<xs:enumeration value="unauthorizedLCSClient"/>
<xs:enumeration value="positionMethodFailure"/>
<xs:enumeration value="unknownOrUnreachableLCSClient"/>
<xs:enumeration value="mmEventNotSupported"/>
<xs:enumeration value="atsiNotAllowed"/>
<xs:enumeration value="atmNotAllowed"/>
<xs:enumeration value="informationNotAvailable"/>
<xs:enumeration value="unknownAlphabet"/>
<xs:enumeration value="ussdBusy"/>
<xs:enumeration value="Unknown"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="userErrorCodeType">
<xs:restriction base="xs:string">
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
81
<xs:enumeration value="appIdAbsent"/>
<xs:enumeration value="appIdInvalid"/>
<xs:enumeration value="appNotActive"/>
<xs:enumeration value="invalidState"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="providerErrorCodeType">
<xs:restriction base="xs:string">
<xs:enumeration value="duplicateInvokeId"/>
<xs:enumeration value="notSupportedService"/>
<xs:enumeration value="mistypedParameter"/>
<xs:enumeration value="resourceLimitation"/>
<xs:enumeration value="initiatingRelease"/>
<xs:enumeration value="unexpectedResponseFromPeer"/>
<xs:enumeration value="serviceCompletionFailure"/>
<xs:enumeration value="noResponseFromPeer"/>
<xs:enumeration value="invalidResponseReceived"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="parameterType">
<xs:restriction base="xs:string">
<xs:enumeration value="msisdn"/>
<xs:enumeration value="imsi"/>
<xs:enumeration value="timeout"/>
<xs:enumeration value="imsi"/>
<xs:enumeration value="alertingPattern"/>
<xs:enumeration value="ussdString"/>
<xs:enumeration value="sessionId"/>
<xs:enumeration value="dest"/>
<xs:enumeration value="orig"/>
<xs:enumeration value="message"/>
<xs:enumeration value="scts"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="geographicalInformationType">
<xs:sequence>
<xs:element name="latitude" type="latitudeType" />
<xs:element name="longitude" type="longitudeType" />
<xs:element name="typeOfShape" type="typeOfShapeType" />
<xs:element name="uncertaintyCode" type="uncertantyCodeType" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="geodeticInformationType">
<xs:sequence>
<xs:element name="latitude" type="latitudeType" />
<xs:element name="longitude" type="longitudeType" />
<xs:element name="typeOfShape" type="typeOfShapeType" />
<xs:element name="uncertaintyCode" type="uncertantyCodeType" />
<xs:element name="screeningIndicator" type="screeningIndicatorType" />
</xs:sequence>
</xs:complexType>
<xs:simpleType name="longitudeType">
<xs:restriction base="xs:double" />
</xs:simpleType>
<xs:simpleType name="latitudeType">
<xs:restriction base="xs:double" />
</xs:simpleType>
<xs:complexType name="cellIdType">
<xs:sequence>
<xs:element name="mcc" type="xs:normalizedString" />
<xs:element name="mnc" type="xs:normalizedString" />
<xs:element name="lac" type="xs:normalizedString" />
<xs:element minOccurs="0" maxOccurs="1" name="ci" type="xs:normalizedString" />
</xs:sequence>
</xs:complexType>
XSD Files
82
<xs:simpleType name="uncertantyCodeType">
<xs:restriction base="xs:double" />
</xs:simpleType>
<xs:simpleType name="typeOfShapeType">
<xs:restriction base="xs:short">
<xs:minInclusive value="0" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="screeningIndicatorType">
<xs:restriction base="xs:short">
<xs:minInclusive value="0" />
</xs:restriction>
</xs:simpleType>
<xs:complexType name="addressFieldType">
<xs:simpleContent>
<xs:extension base="xs:normalizedString">
<xs:attribute name="ton">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Unknown" />
<xs:enumeration value="International" />
<xs:enumeration value="National" />
<xs:enumeration value="NetworkSpecific" />
<xs:enumeration value="Subscriber" />
<xs:enumeration value="Alphanumeric" />
<xs:enumeration value="AbbreviatedNumber" />
<xs:enumeration value="Reserved" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="npi">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Unknown" />
<xs:enumeration value="ISDN" />
<xs:enumeration value="Reserved2" />
<xs:enumeration value="Data" />
<xs:enumeration value="Telex" />
<xs:enumeration value="ServiceCentreSpecific5" />
<xs:enumeration value="ServiceCentreSpecific6" />
<xs:enumeration value="Reserved7" />
<xs:enumeration value="National" />
<xs:enumeration value="Private" />
<xs:enumeration value="ERMES" />
<xs:enumeration value="Reserved11" />
<xs:enumeration value="Reserved12" />
<xs:enumeration value="Reserved13" />
<xs:enumeration value="Reserved14" />
<xs:enumeration value="Reserved" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="tpType">
<xs:sequence>
<xs:element name="mms" type="xs:boolean" />
<xs:element name="rp" type="xs:boolean" />
<xs:element name="udhi" type="xs:boolean" />
<xs:element name="udl">
<xs:simpleType>
<xs:restriction base="xs:short">
<xs:minInclusive value="0" />
<xs:maxInclusive value="160" />
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
83
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="sri" type="xs:boolean" />
<xs:element name="dcs">
<xs:simpleType>
<xs:restriction base="xs:short">
<xs:minInclusive value="0" />
<xs:maxInclusive value="255" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="pid">
<xs:simpleType>
<xs:restriction base="xs:short">
<xs:minInclusive value="0" />
<xs:maxInclusive value="255" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="scts" type="xs:string" />
<xs:element name="ud" type="xs:string" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="moTpType">
<xs:sequence>
<xs:element name="rd" type="xs:boolean" />
<xs:element name="rp" type="xs:boolean" />
<xs:element name="udhi" type="xs:boolean" />
<xs:element name="srr" type="xs:boolean" />
<xs:element name="mr">
<xs:simpleType>
<xs:restriction base="xs:short">
<xs:minInclusive value="0" />
<xs:maxInclusive value="255" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="udl">
<xs:simpleType>
<xs:restriction base="xs:short">
<xs:minInclusive value="0" />
<xs:maxInclusive value="160" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="dcs">
<xs:simpleType>
<xs:restriction base="xs:short">
<xs:minInclusive value="0" />
<xs:maxInclusive value="255" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="pid">
<xs:simpleType>
<xs:restriction base="xs:short">
<xs:minInclusive value="0" />
<xs:maxInclusive value="255" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="ud" type="xs:string" />
<xs:element name="vpRel">
<xs:simpleType>
XSD Files
84
<xs:restriction base="xs:short">
<xs:minInclusive value="0" />
<xs:maxInclusive value="255" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="vpAbs" type="xs:string" />
<xs:element name="vpEnc" type="xs:string" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="oiType">
<xs:sequence>
<xs:element minOccurs="0" name="reqCount">
<xs:simpleType>
<xs:restriction base="xs:int">
<xs:minInclusive value="0" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element minOccurs="0" name="indCount">
<xs:simpleType>
<xs:restriction base="xs:int">
<xs:minInclusive value="0" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element minOccurs="0" name="msc" type="addressFieldType" />
</xs:sequence>
</xs:complexType>
<xs:simpleType name="serviceType">
<xs:restriction base="xs:string">
<xs:enumeration value="sms" />
<xs:enumeration value="smsmo" />
<xs:enumeration value="ussd" />
<xs:enumeration value="location" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="sessionTerminatedType">
<xs:restriction base="xs:int" />
</xs:simpleType>
<xs:simpleType name="alertReasonType">
<xs:restriction base="xs:string">
<xs:enumeration value="msPresent" />
<xs:enumeration value="memoryAvailable" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="smRpMtiType">
<xs:restriction base="xs:string">
<xs:enumeration value="SmsDeliver" />
<xs:enumeration value="SmsStatusReport" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="smDeliveryNotIntendedType">
<xs:restriction base="xs:string">
<xs:enumeration value="imsi" />
<xs:enumeration value="mmc-mnc" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="absentSubDiagSmType">
<xs:restriction base="xs:string">
<xs:enumeration value="noPagingResp" />
<xs:enumeration value="imsiDetached" />
<xs:enumeration value="roamingRestriction" />
<xs:enumeration value="deregisteredHlr" />
<xs:enumeration value="msPurged" />
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
85
<xs:enumeration value="noPagingRespSgsn" />
<xs:enumeration value="deregisteredHlrGprs" />
<xs:enumeration value="msPurgedGprs" />
<xs:enumeration value="unidentifiedSub" />
<xs:enumeration value="unidentifiedSubSgsn" />
<xs:enumeration value="deregisteredHssIms" />
<xs:enumeration value="noRespIpSmGw" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="smDeliveryOutcomeType">
<xs:restriction base="xs:string">
<xs:enumeration value="memoryCapacityExceeded" />
<xs:enumeration value="absentSubscriber" />
<xs:enumeration value="successfulTransfer" />
</xs:restriction>
</xs:simpleType>
<xs:complexType name="informScType">
<xs:sequence>
<xs:element minOccurs="0" name="storedMsisdn" type="addressFieldType" />
<xs:element minOccurs="0" name="mnrf"/>
<xs:element minOccurs="0" name="mcef"/>
<xs:element minOccurs="0" name="mnrg"/>
<xs:element minOccurs="0" name="srvCtrSetInHlr"/>
<xs:element minOccurs="0" name="absentSubDiagSm" type="absentSubDiagSmType" />
<xs:element minOccurs="0" name="addAbsentSubDiagSm" type="absentSubDiagSmType"
/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="locationRspType">
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="1" name="longitude" type="longitudeType"
/>
<xs:element minOccurs="0" maxOccurs="1" name="latitude" type="latitudeType" />
<xs:element minOccurs="0" maxOccurs="1" name="cellId" type="cellIdType" />
<xs:element minOccurs="0" maxOccurs="1" name="geographicalInformation"
type="geographicalInformationType" />
<xs:element minOccurs="0" maxOccurs="1" name="geodeticInformation"
type="geodeticInformationType" />
<xs:element minOccurs="0" maxOccurs="1" name="geographicalInfomationGPRS"
type="geographicalInformationType" />
</xs:sequence>
</xs:complexType>
<xs:simpleType name="requestedDomainType">
<xs:restriction base="xs:string">
<xs:enumeration value="csDomain" />
<xs:enumeration value="psDomain" />
</xs:restriction>
</xs:simpleType>
<xs:complexType name="requestedNodesType">
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="1" name="mme"/>
<xs:element minOccurs="0" maxOccurs="1" name="sgsn"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="gprsMsClassType">
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="1" name="msNetworkCapability"
type="xs:normalizedString"/>
<xs:element minOccurs="0" maxOccurs="1" name="msRadioAccessCapability"
type="xs:normalizedString"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="mnpInfoResType">
<xs:sequence>
XSD Files
86
<xs:element minOccurs="0" maxOccurs="1" name="routingNumber"
type="xs:normalizedString"/>
<xs:element minOccurs="0" maxOccurs="1" name="imsi"
type="xs:normalizedString"/>
<xs:element minOccurs="0" maxOccurs="1" name="msisdn" type="addressFieldType"
/>
<xs:element minOccurs="0" maxOccurs="1" name="numberPortabilityStatus"
type="numberPortabilityStatusType" />
</xs:sequence>
</xs:complexType>
<xs:simpleType name="numberPortabilityStatusType">
<xs:restriction base="xs:string">
<xs:enumeration value="notKnownToBePorted" />
<xs:enumeration value="ownNumberPortedOut" />
<xs:enumeration value="foreignNumberPortedToForeignNetwork" />
<xs:enumeration value="Reserved3"/>
<xs:enumeration value="ownNumberNotPortedOut" />
<xs:enumeration value="foreignNumberPortedIn" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="imsVoiceOverPsSessionsIndicationType">
<xs:restriction base="xs:string">
<xs:enumeration value="imsVoiceOverPsSessionsNotSupported" />
<xs:enumeration value="imsVoiceOverPsSessionsSupported" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="UsedRatTypeType">
<xs:restriction base="xs:string">
<xs:enumeration value="utran" />
<xs:enumeration value="geran" />
<xs:enumeration value="gan" />
<xs:enumeration value="1HspaEvolution" />
<xs:enumeration value="eUtran" />
</xs:restriction>
</xs:simpleType>
<xs:complexType name="subscriberStateType">
<xs:sequence>
<xs:element minOccurs="0" name="notReachable" type="notReachableType"/>
</xs:sequence>
<xs:attribute name="state">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="assumedIdle"/>
<xs:enumeration value="camelBusy"/>
<xs:enumeration value="notReachable"/>
<xs:enumeration value="notProvided"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="psSubscriberStateType">
<xs:sequence>
<xs:element minOccurs="0" name="notReachable" type="notReachableType"/>
</xs:sequence>
<xs:attribute name="state">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="notProvided"/>
<xs:enumeration value="detached"/>
<xs:enumeration value="attachedPagingNotReachable"/>
<xs:enumeration value="attachedPagingReachable"/>
<xs:enumeration value="activePagingNotReachable"/>
<xs:enumeration value="activePagingReachable"/>
<xs:enumeration value="notReachable"/>
</xs:restriction>
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
87
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:simpleType name="notReachableType">
<xs:restriction base="xs:string">
<xs:enumeration value="msPurged"/>
<xs:enumeration value="imsiDetached"/>
<xs:enumeration value="restrictedArea"/>
<xs:enumeration value="notRegistered"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Testing Extensions to the API
88
Client SWS
200 - OK
GET
HLR
Send Routing Info for SM
Send Routing Infor for SM - ReponsePUT
204 - OK
Appendix B. Testing Extensions to the API
B.1 Receiving Atomic Send Routing Info For SM A client can request to receive a Send Routing Info For SM from the network This uses a HTTP GET request and will receive the same XML payload used in
the request. The client will then send a response to send a result to the network using a HTTP PUT request. See the figure below:
Figure 34: Receiving a Send Routing Info For SM
HTTP GET
http://192.168.0.1:81/dialogicwebservice/signaling/sriforsm
The HTTP GET is used to request the next send routing info for SM received by SWS (note that the absence of the MSISDN).
The 20O – OK response code is the expected response to a successfully receive Send Routing Info for SM, it will have payload of the following form:
SEND-ROUTING-FOR-SM-TX-REQ
<?xml version="1.0" encoding="utf-8"?>
<!—- Example SRI sent -->
<sriForSm version="1">
<msisdn ton="International" np="ISDN">447777654321</msisdn>
<sessionId>5</sessionId>
</sriForSm >
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
89
Client SWS
200 - OK
GET
HLR
Ready for SM
Ready for SM - ReponsePUT
204 - OK
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/sriforsm/5
The HTTP Put request is then used to return the result of the Send Routing Info for SM request to the network. For a successful response the XML
payload will have the following form:
<?xml version="1.0" encoding="utf-8"?>
<!-- Example SMS received -->
<sriForSm version="1">
<imsi>5012423432</imsi>
<msc ton="International" np="ISDN">440044001122</msc>
</sriForSm>
To include the sending of inform SC then the payload will have the following form:
<?xml version="1.0" encoding="utf-8"?>
<!-- Example SMS received -->
<sriForSm version="1">
<imsi>5012423432</imsi>
<msc ton="International" np="ISDN">440044001122</msc>
<informSC>
<storedMsisdn ton="Unknown" np="ISDN">44777765</storedMsisdn>
<mnrf/>
</informSC>
</sriForSm>
B.2 Receiving Ready For SM A client can request to receive a Ready For SM from the network This uses a
HTTP GET request and will receive the same XML payload used in the request. The client will then send a response to send a result to the network using a HTTP PUT request. See the figure below:
Figure 35: Receiving a Ready For SM
Testing Extensions to the API
90
HTTP GET
http://192.168.0.1:81/dialogicwebservice/signaling/readyforsm
The HTTP GET is used to request the next ready for SM received by SWS (note that the absence of the MSISDN).
The 20O – OK response code is the expected response to a successfully receive Ready For SM, it will have payload of the following form:
READY-FOR-SM-RX-REQ
<?xml version="1.0" encoding="utf-8"?>
<!—- Example SRI sent -->
<readyForSm version="1">
<imsi>234153121235437</imsi>
<alertReason>msPresent</alertReason>
<hlrAddr ton="International" np="ISDN">440044001122</hlrAddr>
<sessionId>2</sessionId>
</readyForSm>
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/readyforsm/2
The HTTP Put request is then used to return the result of the Ready for SM request to the network. For a successful response the XML payload will have the following form:
<?xml version="1.0" encoding="utf-8"?>
<!-- Example SMS received -->
<readyForSm version="1">
<sessionId>2</sessionId>
</readyForSm>
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
91
Client SWS
200 - OK
GET
HLR
Report SM Delivery
Report SM Delivery - ResponsePUT
204 - OK
B.3 Receiving Report SM Delivery A client can request to receive a Report SM Delivery from the network This uses a HTTP GET request and will receive the same XML payload used in the
request. The client will then send a response to send a result to the network using a HTTP PUT request. See the figure below:
Figure 36: Receiving a Report SM Delivery
HTTP GET
http://192.168.0.1:81/dialogicwebservice/signaling/reportSMDelive
r
The HTTP GET is used to request the next Report SM Delivery received by SWS.
The 20O – OK response code is the expected response to a successfully receive Report SM Delivery, it will have payload of the following form:
<?xml version="1.0" encoding="utf-8"?>
<!—- Example Report SM Delivery rcvd -->
<reportSMDeliver version="1">
<msisdn ton="International" np="ISDN">447777654321</msisdn>
<deliveryOutcome>successfulTransfer</deliveryOutcome>
<sessionId>6</sessionId>
</reportSMDeliver>
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/reportsmdelive
r/2
The HTTP Put request is then used to return the result of the Report SM
Delivery request to the network. For a successful response the XML payload will have the following form:
Testing Extensions to the API
92
Client SWS
200 - OK
GET
HLR
ATI (location request)
ATI Response (location)PUT
204 - OK
<?xml version="1.0" encoding="utf-8"?>
<!-- Example SMS received -->
<reportSMDeliver version="1">
<sessionId>2</sessionId>
</reportSMDeliver >
B.4 Receiving Location Request A client can request to receive a Location Request from the network This uses a HTTP GET request and will receive the same XML payload used in the request. The client will then send a response to send a result to the network using a HTTP PUT request. See the figure below:
Figure 37: Receiving a Location Request
HTTP GET
http://192.168.0.1:81/dialogicwebservice/signaling/location
The HTTP GET is used to request the next Location request received by SWS (note that the absence of the MSISDN).
The 20O – OK response code is the expected response to a successfully
receive Location Request, it will have payload of the following form:
<?xml version="1.0" encoding="utf-8"?>
<!—- Example Report SM Delivery rcvd -->
<location version="1">
<msisdn ton="International" np="ISDN>447777123456</msisdn>
<sessionId>2231</sessionId>
</location>
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
93
Client SWS
200 - OK
GET
HLR
ATI (subscriber state request)
ATI Response (subscriber state)PUT
204 - OK
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/location/2231
The HTTP Put request is then used to return the result of the Location Request response to the network. For a successful response the XML payload
will have the following form:
<?xml version="1.0" encoding="utf-8"?>
<!-- Example Location Resp -->
<location version="1">
<latitude>37.56509</latitude>
<longitude>-96.38509</longitude>
<sessionId>2231</sessionId>
</location >
B.5 Receiving Subscriber State Request A client can request to receive a Subscriber State Request from the network This uses a HTTP GET request and will receive the same XML payload used in the request. The client will then send a response to send a result to the network using a HTTP PUT request. See the figure below:
Figure 38: Receiving a subscriber state Request
HTTP GET
http://192.168.0.1:81/dialogicwebservice/signaling/subscriberstat
e
The HTTP GET is used to request the next Location request received by SWS
(note that the absence of the MSISDN).
The 20O – OK response code is the expected response to a successfully
receive Subscriber State Request, it will have payload of the following form:
Testing Extensions to the API
94
<?xml version="1.0" encoding="utf-8"?>
<!—- Example Report SM Delivery rcvd -->
<subscriberState version="1">
<msisdn ton="International" np="ISDN>447777123456</msisdn>
<sessionId>2231</sessionId>
</subscriberState>
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/subscriberstat
e/2231
The HTTP Put request is then used to return the result of the Subscriber State response to the network. For a successful response the XML payload will have the following form:
<?xml version="1.0" encoding="utf-8"?>
<!-- Example Location Resp -->
<location version="1">
<state state="assumedIdle"/>
<sessionId>2231</sessionId>
</location >
Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4
95
Client SWS
204 - No content
PUT Alert Service Centre
Alert Service Centre - response
Network
B.6 Transmitting Alert Service Centre Request A client can request that an Alert Service Centre be used sent to the Nework. This uses a HTTP PUT request. See the figure below:
Figure 39: Transmitting a Alert Service Centre
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/alertsc
The payload is mandatory. See Appendix A.1 for the supporting XSD schema.
ALERT-SC-TX-REQ
<?xml version="1.0" encoding="utf-8"?>
<!—- Example SRI sent -->
<sriForSm version="1">
<msisdn ton="International" np="ISDN">447777654321</msisdn>
</sriForSm >
The response should include a 204 OK for success. In other cases an appropriate response code will be used as shown in section 3.2.3.
Testing Extensions to the API
96
Client SWS
200 - OK
GET
HLR
PUT
204 - OK
Send IMSI Request
Send IMSI Response
B.7 Receiving Get IMSI Request A client can request to receive a Get Imsi Request from the network This uses a HTTP GET request and will receive the same XML payload used in the
request. The client will then send a response to send a result to the network using a HTTP PUT request. See the figure below:
Figure 40: Receiving a Get IMSI Request
HTTP GET
http://192.168.0.1:81/dialogicwebservice/signaling/getimsi
The HTTP GET is used to request the next Send IMSI received by SWS (note that the absence of the MSISDN).
The 20O – OK response code is the expected response to a successfully receive Subscriber State Request, it will have payload of the following form:
<?xml version="1.0" encoding="utf-8"?>
<!—- Example Report SM Delivery rcvd -->
<getImsi version="1">
<msisdn ton="International" np="ISDN>447777123456</msisdn>
<sessionId>2231</sessionId>
</getImsi>
HTTP PUT
http://192.168.0.1:81/dialogicwebservice/signaling/getimsi/2231
The HTTP Put request is then used to return the result of the Get IMSI response to the network. For a successful response the XML payload will have the following form: