bulkgateway_clientusersguide · web view(b/w) nokia bookmarks nokia x x x x sagem x motorola x...

WIRELESS INFORMATION NETWORK LTD

WIN GatewayVersion 3.2

Interface Definition Document

Revision 3.2.01

3rd February 2006

Confidential

Wireless Information Network Ltd.

The information contained herein is the property of the Wireless Information Network, and may not be copied, used or disclosed in whole or in part, except with the prior written permission of the Wireless Information Network.

WIN - Confidential Page i of vii Printed 18/05/23Gateway Interface Definition Document

Document Revision History

Date Revision

Authors Document Section(s), Comments/Reasons For Change

30 January 2002

1.0 C. E. Ley Initial version

19 January 2002

1.1 C. E. Ley Updates

28 February 2002

1.2 C. E. Ley Processed subdirectory updates

8 March 2002 1.3 C. Perris Updated sections 2.2.1, 5 and 6.18 March 2002 1.4 C. E. Ley Updated sections 2.2.1, 5 and 6 and in XML * to +27 March 2002 1.5 C. E. Ley Clarification of http POST interface section 2.2.1.114 June 2002 1.6 C. E. Ley Correction to 2.2.1.1

11 October 2002

1.7 C. E. Ley 10.7 tpbound_messages_v1.dtd to include a timestamp, WINTRANSACTIONID added to winbound_messages_v1.dtd. DELIVERYRECEIPT possible values changed.

21st October 2002

1.8 C. E. Ley Clarifications. No functional changes.

17th December 2002

1.9 C. E. Ley XML Encoding changes and a new section (1.5) to indicate what features within this document have not been implemented.

14th January 2003

2.0 C. Perris Update section 7.1 Web Reporting.

24th January 2003

2.1 C. E. Ley Change of directory structures to include hourly subdirectories.

30th January 2003

2.2 C. E. Ley Description added of new HTTP GET WINBound capability

26th February 2003

2.3 C. E. Ley Changed TPBound FTP to place files on the client’s FTP server rather than WIN’s FTP servers.

6th March 2003 2.4 C. E. Ley Improved QAs with respect to XML1st April 2003 2.5 C. E. Ley New HTTP Gateway URL and description3rd April 2003 2.6 R. Wilson New Gateway Admin Reporting Screens that make

use ofTemplate Customer implementation.

19th June 2003 2.7 C. E. Ley New networks Germany, Ireland and Spain : 8.4.1and 8.6.1

18th July 2003 2.8 C. E. Ley Test URL added and two new customer visible response codes added : 4.1, 8.82 . Also test.html updated.

04th August 2003

2.9 C. Perdreau

Added section “9 Using WIN Converters For Ring tones, Logos, etc.” and updated section “10.7How do I send a message type other than text e.g. a ring tone, logo etc”

4th December 2003

2.10 C. E. Ley Message type 11 and 12

2nd April 2004 2.11 J. Rands Revision to “Feature not yet available”

WIN - Confidential Page ii of vii Printed 18/05/23Gateway Interface Definition Document

5th April 2004 3.0 J. Rands Incorporation of V3 gateway functions7th April 2004 3.01 C. E. Ley General Review esp. new Delivery Receipts6th May 2004 3.02 C. E. Ley Delivery Receipts to include Seconds.

New Delivery Statuses added : 14, 15, 163rd June 2004 3.03 C. E. Ley Test Key word

22nd Sept 2004 3.04 C. E. Ley Split ‘User Guide’ document into the ‘Interface Definition Document’ and the ‘Operators’ Guide’ to target different audiences.

27th October 2004

3.05 C. E. Ley Additional delivery receipts : Win barred and Phone barred

26th January 2004

3.06 C. E. Ley New implementation of WAPPush section 8.4

11th March 3.07 J. Rands Clarification on test message section 1.9531st March 3.08 J. Rands Add 3# retry scenario

14th April 2005 3.09 C. E. Ley GatewayDemo references included20th May 2005 3.1.01 C. E. Ley Restructured Document. Introduction of version 3.1 of

gateway : Addition of IMSI functionality. Changes to available routing types.

3rd September 2005

3.1.02 C. E. Ley Updated structure for delivery receipts v3p1 XML

3rd February 2006

3.2.02 C. E. Ley Multipart messages, FTP 3.2 upgrade, DTD updates (clarifications)

Updates of this, related documents, and samples are available at:

http://www.wincast.com/gatewaydemo/smsHTTP/readme.htm

WIN - Confidential Page iii of vii Printed 18/05/23Gateway Interface Definition Document


Table of Contents – Summary(Sections of to a depth of two displayed only)

1 INTRODUCTION...................................................................................................11.1 PURPOSE OF THIS DOCUMENT...................................................................................11.2 SCOPE..................................................................................................................... 11.3 REFERENCED DOCUMENTS........................................................................................11.4 ABBREVIATIONS AND ACRONYMS..............................................................................11.5 KEY GATEWAY FEATURES........................................................................................21.6 DOCUMENTED FEATURES NOT CURRENTLY AVAILABLE...............................................2

2 SYSTEM OVERVIEW.................................................................................................32.1 SUMMARY................................................................................................................. 32.2 LOGICAL PROTOCOL.................................................................................................42.3 COMMUNICATIONS TRANSPORT.................................................................................62.4 KEY GATEWAY PARAMETER LIMITS...........................................................................6

3 GATEWAY VERSION UPGRADE GUIDE.......................................................................73.1 GENERAL................................................................................................................. 73.2 V3.1 TO V3.2 GATEWAY UPDATE..............................................................................83.3 V3.0 TO V3.1 GATEWAY UPDATE............................................................................103.4 V2.X TO V3.0 GATEWAY UPDATE............................................................................12

4 HTTP....................................................................................................................154.1 OVERVIEW..............................................................................................................154.2 HTTP WINBOUND PROCESS DESCRIPTION.............................................................164.3 HTTP TPBOUND PROCESS DESCRIPTION...............................................................20

5 FTP......................................................................................................................225.1 OVERVIEW..............................................................................................................225.2 FTP WINBOUND PROCESS DESCRIPTION................................................................245.3 FTP TPBOUND PROCESS DESCRIPTION..................................................................27

6 XML DEFINITIONS AND EXAMPLES.........................................................................286.1 WINBOUND : MESSAGES TO SEND TO MOBILES........................................................296.2 TPBOUND : MESSAGES RECEIVED FROM CUSTOMERS..............................................346.3 TPBOUND : DELIVERY RECEIPTS.............................................................................356.4 GENERIC RESPONSE...............................................................................................41

7 PAYLOAD TYPES....................................................................................................437.1 PLAIN TEXT PAYLOAD.............................................................................................437.2 BINARY PAYLOAD WITH USER DEFINED HEADER......................................................437.3 BINARY PAYLOAD WITHOUT USER DEFINED HEADER................................................447.4 WAPPUSH AND BOOKMARKS.................................................................................45

8 USING WIN CONVERTERS FOR RING TONES, LOGOS, ETC......................................488.1 SUPPORTED FEATURES AND HANDSETS...................................................................488.2 RING TONES...........................................................................................................488.3 OPERATOR LOGOS.................................................................................................488.4 PICTURE MESSAGES...............................................................................................498.5 NOKIA BOOKMARK.................................................................................................498.6 INTERNATIONAL MOBILE SUBSCRIBER IDENTITY (IMSI) LOOKUP...............................50

9 FAQ.....................................................................................................................529.1 GENERIC TECHNICAL QUESTIONS............................................................................529.2 WIN Product Specific............................................................................................54

WIN - Confidential Page iv of vii Printed 18/05/23Gateway Interface Definition Document

WIN - Confidential Page v of vii Printed 18/05/23Gateway Interface Definition Document

Table of Contents - Detailed(All Sections displayed)

1 INTRODUCTION...................................................................................................11.1 PURPOSE OF THIS DOCUMENT...................................................................................11.2 SCOPE..................................................................................................................... 11.3 REFERENCED DOCUMENTS........................................................................................11.4 ABBREVIATIONS AND ACRONYMS..............................................................................11.5 KEY GATEWAY FEATURES........................................................................................21.6 DOCUMENTED FEATURES NOT CURRENTLY AVAILABLE...............................................2

2 SYSTEM OVERVIEW.................................................................................................32.1 SUMMARY................................................................................................................. 32.2 LOGICAL PROTOCOL.................................................................................................4

2.2.1 SEND MESSAGES TO MOBILE USERS..........................................................................................42.2.2 FORWARD SMS MESSAGES FROM MOBILE USERS TO THIRD PARTY............................................52.2.3 DELIVERY RECEIPTS TO THIRD PARTY........................................................................................52.2.4 PROVIDES ONLINE REPORTS TO THE THIRD PARTY.....................................................................52.2.5 TEST KEYWORD.......................................................................................................................5

2.3 COMMUNICATIONS TRANSPORT.................................................................................62.3.1 GENERAL.................................................................................................................................6

2.4 KEY GATEWAY PARAMETER LIMITS...........................................................................62.4.1 IP RESTRICTION.......................................................................................................................6

3 GATEWAY VERSION UPGRADE GUIDE.......................................................................73.1 GENERAL................................................................................................................. 73.2 V3.1 TO V3.2 GATEWAY UPDATE..............................................................................8

3.2.1 SUMMARY OF IMPROVEMENTS...................................................................................................83.2.2 CHANGES REQUIRED – MULTIPART MESSAGES..........................................................................83.2.3 CHANGES REQUIRED - FTP CLIENTS........................................................................................9

3.3 V3.0 TO V3.1 GATEWAY UPDATE............................................................................103.3.1 SUMMARY OF IMPROVEMENTS.................................................................................................10

3.3.1.1 STANDARD MTS.............................................................................................................103.3.1.2 INTERNATIONAL MOBILE SUBSCRIBER IDENTITY..............................................................10

3.3.2 CHANGES REQUIRED..............................................................................................................103.3.2.1 DTD RELEVANT EXTRACTS.............................................................................................11

3.4 V2.X TO V3.0 GATEWAY UPDATE............................................................................123.4.1 SUMMARY OF IMPROVEMENTS.................................................................................................123.4.2 CHANGES REQUIRED..............................................................................................................123.4.3 RAW POST EXAMPLES OF CHANGES......................................................................................13

3.4.3.1 EXAMPLE V3 TPBOUND HTTP POST............................................................................133.4.3.2 EXAMPLE V2 TPBOUND HTTP POST............................................................................13

3.4.4 UPGRADE FROM V2 TO V3 TEST FORM...................................................................................14

4 HTTP....................................................................................................................154.1 OVERVIEW..............................................................................................................154.2 HTTP WINBOUND PROCESS DESCRIPTION.............................................................16

4.2.1 THIRD PARTY PROCESS DESCRIPTION....................................................................................164.2.1.1 METHOD: POST DETAIL................................................................................................17

4.2.1.1.1 ENCODING TYPE......................................................................................................174.2.1.1.2 RAW POST EXAMPLES..........................................................................................18

4.2.1.2 METHOD: GET...............................................................................................................184.2.2 WIN PROCESS DESCRIPTION..................................................................................................194.2.3 GENERIC RESPONSE CODE....................................................................................................19

WIN - Confidential Page vi of vii Printed 18/05/23Gateway Interface Definition Document

4.3 HTTP TPBOUND PROCESS DESCRIPTION...............................................................204.3.1 WIN PROCESS DESCRIPTION..................................................................................................204.3.2 METHOD POST DETAIL..........................................................................................................20

4.3.2.1 RAW POST EXAMPLE...................................................................................................204.3.3 THIRD PARTY PROCESS DESCRIPTION....................................................................................21

5 FTP......................................................................................................................225.1 OVERVIEW..............................................................................................................22

5.1.1 MAXIMUM FILE SIZE................................................................................................................235.1.2 FOLDER STRUCTURE..............................................................................................................23

5.2 FTP WINBOUND PROCESS DESCRIPTION................................................................245.2.1 THIRD PARTY PROCESS DESCRIPTION....................................................................................24

5.2.1.1 ESTABLISHING A CONNECTION.......................................................................................245.2.1.2 LIFE TIME OF THE CONNECTION.....................................................................................245.2.1.3 FILE TRANSFER..............................................................................................................24

5.2.1.3.1 FILE NAMING CONVENTION.......................................................................................245.2.1.4 RETRY STRATEGY..........................................................................................................255.2.1.5 FILE CONTENT...............................................................................................................255.2.1.6 HEART BEAT MESSAGES - OPTIONAL.............................................................................255.2.1.7 ERROR REPORTING........................................................................................................25

5.2.2 WIN PROCESS DESCRIPTION..................................................................................................265.2.2.1 WINBOUND FILE DETECTION..........................................................................................265.2.2.2 WINBOUND FILE MOVEMENT AND DELETION....................................................................265.2.2.3 WINBOUND FILE PROCESSING........................................................................................26

5.3 FTP TPBOUND PROCESS DESCRIPTION..................................................................275.3.1 WIN PROCESS DESCRIPTION..................................................................................................275.3.2 THIRD PARTY PROCESS DESCRIPTION....................................................................................27

6 XML DEFINITIONS AND EXAMPLES.........................................................................286.1 WINBOUND : MESSAGES TO SEND TO MOBILES........................................................29

6.1.1 DTD DEFINITION : WINBOUND_MESSAGES_V1.DTD..................................................................296.1.2 XML EXAMPLE......................................................................................................................33

6.2 TPBOUND : MESSAGES RECEIVED FROM CUSTOMERS..............................................346.2.1 DTD DEFINITION : TPBOUND_MESSAGES_V1.DTD....................................................................346.2.2 XML EXAMPLE......................................................................................................................34

6.3 TPBOUND : DELIVERY RECEIPTS.............................................................................356.3.1 DTD DEFINITION : TPBOUND_RECEIPTS_V3P1.DTD..................................................................356.3.2 XML EXAMPLE......................................................................................................................376.3.3 GATEWAY STATUSID VALUES................................................................................................386.3.4 MT RETRY STRATEGY............................................................................................................40

6.4 GENERIC RESPONSE...............................................................................................416.4.1 DTD DEFINITION : RESPONSE_GENERIC_V1.DTD.....................................................................416.4.2 XML EXAMPLE......................................................................................................................42

7 PAYLOAD TYPES....................................................................................................437.1 PLAIN TEXT PAYLOAD.............................................................................................437.2 BINARY PAYLOAD WITH USER DEFINED HEADER......................................................437.3 BINARY PAYLOAD WITHOUT USER DEFINED HEADER................................................447.4 WAPPUSH AND BOOKMARKS.................................................................................45

7.4.1 MULTIPLE PULLS TO THE SAME URL.......................................................................................46JUST STARTING OUT WITH WAP ?......................................................................................................47

7.4.1.1 YOU CAN DOWNLOAD A DESKTOP BROWSER THAT IS CAPABLE OF VIEWING WAP PAGES...477.4.1.2 HELLO WORLD EXAMPLE :..............................................................................................477.4.1.3 ON-LINE WAP / WML TUTORIAL....................................................................................477.4.1.4 WYSIWYG TOOLS.........................................................................................................47

8 USING WIN CONVERTERS FOR RING TONES, LOGOS, ETC......................................48WIN - Confidential Page vii of vii Printed 18/05/23Gateway Interface Definition Document

8.1 SUPPORTED FEATURES AND HANDSETS...................................................................488.2 RING TONES...........................................................................................................488.3 OPERATOR LOGOS.................................................................................................488.4 PICTURE MESSAGES...............................................................................................498.5 NOKIA BOOKMARK.................................................................................................498.6 INTERNATIONAL MOBILE SUBSCRIBER IDENTITY (IMSI) LOOKUP...............................50

8.6.1 BACKGROUND TO PRODUCT....................................................................................................508.6.2 BENEFITS...............................................................................................................................508.6.3 HOW TO MAKE USE OF THIS SERVICE......................................................................................51

9 FAQ.....................................................................................................................529.1 GENERIC TECHNICAL QUESTIONS............................................................................52

9.1.1 I AM NEW TO XML OR WAP, HOW CAN I GET UP TO SPEED ?..................................................529.1.2 HOW DO I PRESENT A POUND SIGN/OTHER SYMBOL IN THE TEXT MESSAGE IN THE XML ?........529.1.3 THE USE OF CDATA SECTIONS WITHIN THE TEXT ELEMENT SEEMS A BIT CLUNKY – DO I HAVE TO USE IT ?........................................................................................................................................539.1.4 THE TPBOUND MESSAGES I RECEIVE CONTAIN THINGS LIKE &GT; AND &#X20AC WHEN THE CUSTOMER DID NOT TYPE THIS ON THEIR PHONE ?..............................................................................539.1.5 HOW DO I ENCODE PARAMETERS PRIOR TO A HTTP POST ?.................................................53

9.2 WIN PRODUCT SPECIFIC.........................................................................................549.2.1 IF I WHERE TO TEXT SOMEBODY AND THEY REPLIED TO MY TEXT, IS THERE ANY WAY OF LINKING THE REPLY TO THE ORIGINAL TEXT ?...................................................................................................549.2.2 HOW DO I REQUEST A LINE BREAK IN A TEXT MESSAGE ?........................................................549.2.3 WHY IS A PARTICULAR NOT CORRECTLY DISPLAYED ON A PHONE ?.........................................549.2.4 HOW DO I SEND A MESSAGE TYPE OTHER THAN TEXT E.G. A RING TONE, LOGO ETC.................54

9.2.4.1 I WANT TO DO THE ENCODING MYSELF.............................................................................549.2.4.2 I WANT WIN TO DO THE ENCODING FOR ME.....................................................................55

9.2.5 QAS ON DELIVERY RECEIPTS.................................................................................................56

WIN - Confidential Page viii of vii Printed 18/05/23Gateway Interface Definition Document

1 INTRODUCTION

1.1 Purpose of this DocumentThe purpose of this document is to present a definition of the interface between the WIN and a third party and to provide a framework for agreeing third party configuration data to enable the third party to use the service. The purpose of the interface is to enable WIN to deliver and receive messages and Network lookup requests to and from mobile providers on behalf of the third party client.

1.2 Scope This document does not cover the commercial terms for example use of individual networks, reverse billing nor does it suggest possible third party service structures.

It is necessary for a third party to have agreed and completed a Client Application Form to proceed with the use of this interface.

1.3 Referenced Documents

Title Purpose OwnerInterface Definition Document

Specification from client perspective. WIN Development

Operator’s Guide Guide for online reporting and query capabilities.

WIN Technical Support Group

Client Application Form

The template for this is the client configuration template document.


WIN Common Identifiers

The contains the list of possible NetworkID values


1.4 Abbreviations and Acronyms

Term Full NameSMS Short Message Service (commonly known as “text”)WIN Wireless Information Network plcTP Third Party. This a direct client of WINs. i.e. not a mobile phone end user.TPBound refers to communication from WIN to the third party.

This is typically mobile phone originated messages or delivery statuses.WINBound refers to communication to WIN from the third party.

This is typically requests for messages to be delivered to mobile phones.FOC Free of Charge (used in respect of cost to the mobile end userPR Premium RateSNR Single Network RoutedOA Substitution Originator Address Substitution, sometimes referred to as ‘spoofing’UDH User Defined HeaderIMSI International Mobile Subscriber Identity

MO Mobile Originated SMS message i.e. A SMS message a customer has sent to a shortcode.

MT Mobile Terminated SMS message i.e. A SMS message sent to a customer.

WIN - Confidential Page 1 of 57 Printed 18/05/23 Gateway Interface Definition Document

BOM Byte Order Mark

1.5 Key Gateway Features

The WIN Gateway Currently supports the following Features: Communication by HTTP(S) And FTP Connection via Redundant ISP’s (referred to as dual ISP) Connection accepted via VPN, private circuits. MO and MT messaging, both Free to user and Premium Rate Detailed Delivery Receipting with option mobile operator Identity On-Line traffic reports WAP Push and Bookmark Encoding IMSI network identification search facility Dynamic Originating address substitution (commonly referred to as OA sub or

Spoofing) High Capacity throughput Binary data support Encoding for monophonic ring tones Encoding for images (wallpapers, Logo’s) IP restricted for improved security (together with other features)

1.6 Documented Features not currently available

Some of the features documented are not currently available.

At present these are as follows:

When sending a message some capabilities have not yet been implemented :These correspond to within winbound_messages_v1.dtd :

LOCATION, FLASH, BLINK, REMOVE.


2 System Overview

2.1 Summary

The Message Gateway functionality is as follows:

1. Send messages to mobile users that have been received from the third party2. Send messages to third party that have been received, via the operators, from mobile

users3. Send delivery receipts to third party that have been received, via the operators, from

mobile users.4. Provide online reports to the third party.5. Provide online query facilities.

The XML interface allows for communication to take place via FTP and HTTP.

WIN can cater for the third party to have a number of message services (i.e. projects) within their organization within which there are a number of third party message types.

The third party specifies for a service : the type of communication channel to WIN (referred to here after as WINBound) and from WIN (referred to here after as TPBound).

The selection of the various configuration values are achieved by completing the Application Form with the assistance of the WIN business analyst.

The degree of service breakdown and message type granularity provided will be directly reflected the level of detail available in the online reports available.

The supported payload types are : plain text, binary (with or without User Defined Header (UDH)), WAPPush Bookmarks


2.2 Logical Protocol

2.2.1 Send messages to mobile usersThe capability provided is for third parties to provide an agreed XML format to WIN that will instruct WIN to dispatch a batch of short messages.

The XML format caters for specifying, per message, the following information : destination phone no.message contentthird party transaction IDthird party message typethird party message servicereverse billing charge bandmobile network of recipientmessage delivery timemessage expiry timespoofing of ‘from’ fieldblinking and flashingdelivery status request

The charging of a mobile user for delivered messages is known as ‘reverse billing’ or ‘premium rate’.

The format enables messages to be sent reverse billed or for free to the recipient by specifying the billing charge band.

Although commonality have improved, not all networks have the same available Price Points so a cross network service may have to have a slightly varying cost to the end user dependent upon their network.

It can be requested that messages are delivered immediately or be scheduled for dispatch at specific delivery times up to 7 days in advance.

The expiry time of individual messages can be set. (E.g. dependent on the information content )

Exact expiry times will be as close as possible to Operator supported times.

Summary information of the status of received instructions can be monitored by the third party via a website and via the HTTP or FTP interface in response to a request.

The client is responsible for the purpose and content of the messages.


2.2.2 Forward SMS messages from mobile users to third partyMessages received via the network operators from mobile operators can be forwarded in an XML format back to the relevant third party. This flow of information is referred to as TPBound (third party bound).

2.2.3 Delivery receipts to third partyThe capability is provided to request a delivery receipt for an SMS message where available from the network provider and return the message status back to the third party.

This will ordinarily be event driven by, for HTTP WIN POSTing to the third party website when WIN detects a change in status or for FTP by the placing of the XML file detailing updated status in the TPBound directory .

2.2.4 Provides online reports to the third partyVarious report summaries are provided at the administration website. This allow totals to be broken down by various metrics. For example Service, Service Group, Type, Network etc. Service Groups allow a group of service ids to be grouped and reported upon so that a third parties that act as resellers can more easily account to their own clients. See later section for detailed description of the reports.

2.2.5 Test KeywordAs part of the commissioning of a client, the client must implement a test keyword.This is to enable WIN and the 3rd Party to prove the connectivity between the 3rd Party and WIN.

The 3rd Party will respond to the Test Keyword by sending a single free MT message to the mobile that sent the WINTEST Keyword.

The 3rd Party should use the WINTEST Service ID (typically ServiceID 1), this ServiceID should not be used to carry live traffic for any other service.

The message should contain the date and time of when the MO message was received by the 3rd Party and the date and time when the MT message is submitted back to WIN. It should also contain the 3rd Party name.

An example message of what to send is:

User sends in WINTEST (arrives via TP bound on ServiceID 1)

3rd Party Responds = “3rrPartyNameTEST received 02/08/04 13:01.23 sent 02/08/04 13:01.34”

So if the 3rd party was the BBC it would be “BBCTEST received 02/08/04 13:01.23 sent 02/08/04 13:01.34”

If another time zone is used for the time stamp, this should be clearly indicated, e.g. CET


2.3 Communications Transport

2.3.1 GeneralThe currently available transports are :

HTPP (Form encoded parameters) FTP

Note new functionality is typically made available via the HTTP gateway variant first.

It is possible to specify different protocols in different directions TPBound and WINBound.

The specific communication transports are described in greater detail within later document sections.

2.4 Key Gateway Parameter Limits

The following are parameters within this document that have been summarised for convenience:

IP Restricted access : A maximum of 6 IP addresses can be specified.

The number of items to WIN or from WIN (messages, delivery receipt requests etc ) per XML submission is limited based on the class of communication technique.

HTTP Max number of items within a single post TO WIN (WINBound) = 50 Max number of items within a single post TO client (TPBound) = 50 Max number of concurrent sessions to WIN (WINBound) = 10 Max number of concurrent sessions to client (TPBound) = 16 The request timeout TPBound is currently 40 seconds however this is going to be

reduced to an eventual target of around 10 seconds.

FTP Maximum file size to or from WIN = 500 Kb

o This is approximately: Either 8500 messages if same messages content for each target phone number (i.e. multiple DESTINATION_ADDR elements). Or 1200 messages if different messages content for each target phone number (i.e. multiple SMSMESSAGE elements).

2.4.1 IP RestrictionAll connections to the gateway will be IP restricted. Only connections from known provisioned IP addresses will be allowed through the WIN firewall to Gateway.

ALL IP’s, including test addresses must be provided by clients for V3 access.

Individual IPs must be specified – e.g. a full class C IP range is not acceptable.A maximum of 6 IP addresses can be specified.


3 Gateway Version Upgrade Guide

3.1 GeneralThose clients that are new to the product need not read this section.

This section is relevant to existing gateway clients that are currently using a previous version of the gateway and are looking to take advantage of the new features, improved functionality and performance of a more recent Gateway version.

Advisory Situation :

HTTP clients :

An upgrade to version 3.X is strongly recommended.This will be made compulsory soon.

No compulsion is placed on upgrading from version 3.0/3.1 to Version 3.2.

FTP clients :

An upgrade to version 3.2 is strongly recommended.This will be made compulsory soon.


3.2 V3.1 to V3.2 Gateway Update

3.2.1 Summary of ImprovementsMain Features

Multipart MT messages. The FTP capabilities have been aligned with the HTTP version of the gateway.

Notably : o Acceptance of Unicode files containing UTF8 encoded XML. o The IMSI lookup capabilityo Multipart MT messageso Any new improvements to the HTTP MT receiving website will be

simultaneously available via the FTP gateway

3.2.2 Changes Required – multipart messagesClients wishing to dispatch multipart SMS messages can now do so by providing multiple TEXT elements within an SMSMESSAGE block.

E.g.

<?xml version="1.0" standalone="no"?><!DOCTYPE WIN_DELIVERY_2_SMS SYSTEM "winbound_messages_v1.dtd">

<WIN_DELIVERY_2_SMS> <SMSMESSAGE> <DESTINATION_ADDR>+448940123456</DESTINATION_ADDR> <TEXT>part 1 </TEXT> <TEXT>part 2 </TEXT> <TEXT>part 3 </TEXT> <TEXT>part 4 </TEXT> <TEXT>part 5 </TEXT> <TEXT>part 6 </TEXT> <TEXT>part 7 </TEXT> <TEXT>part 8 </TEXT> <TEXT>part 9 </TEXT> <TEXT>part 10 </TEXT> <TRANSACTIONID>333444</TRANSACTIONID> <TYPEID>2</TYPEID> <SERVICEID>1</SERVICEID> <COSTID>1</COSTID> </SMSMESSAGE></WIN_DELIVERY_2_SMS>

All leading and trailing spaces are maintained and presented to the network operators.

Note not all phones support multipart messages, however for those that do, it is believed that up to 10 is a capability that can be considered supported.

Multipart MT messages can be dispatched only via certain network operators and at certain end user charge rates. Clients please discuss the possibilities with WIN prior to use.

The forwarding of multipart MOs to clients is not available at this time.


3.2.3 Changes Required - FTP clientsThe improvements are only available once a client requests and WIN upgrades their configuration to be a ‘3.2’ gateway client. This is configurable per ServiceID.

Note changing the designation of an HTTP client from 3.1. to 3.2 will not result in any necessity for client integration testing and no new functionality will be available.

Unicode files may be presented with Byte Order Marks (BOM) indicating the file is byte ordered using one of the following : UTF8, UTF16LE or UTF16BE. If no BOM is present UTF8 will be assumed.

It is likely that a client application will simply generate Unicode files when generating UTF8 encoded XML and that the client need not have or undertake any detailed knowledge/ research, however if it proves necessary, some sources of background reading on file byte encoding types and Byte Order Marks are available at :

http://en.wikipedia.org/wiki/Byte_Order_MarkWhere no BOM is provided utf-8 is assumed. As recommended by :http://www.opentag.com/xfaq_enc.htmhttp://www.unicode.org/unicode/faq/utf_bom.html#BOM

This allows for the transmission of a wide variety of characters on to the WIN platform via FTP. Note character support by network operators varies.

Existing FTP clients may need to modify slightly the MT request XML that is being presented :

1) It must be fully compliant with the XML winbound_messages_v1.dtd definition contained within this document. Note the readme page contains an electronic copy of this and example XML files.

E.g.1.The DTD requires elements to occur in a specific order whereas the earlier WIN FTP gateway versions where tolerant of the order of elements.

E.g.2.The earlier WIN FTP gateway versions allowed additional unspecified elements to be present in the XML. E.g. in a very early version of the gateway documentation login and password elements where shown in some example XML.

2) Furthermore 3.2 enforces that the only XML encoding type that will be accepted is utf-8.

i.e. The first line the file will need to be one of the following :<?xml version="1.0" standalone="no"?><?xml version="1.0" encoding="utf-8" standalone="no"?>

3) The document type must be stated within the XML.

i.e. for MT request(s) the second line in a file should be :<!DOCTYPE WIN_DELIVERY_2_SMS SYSTEM "winbound_messages_v1.dtd">


http://www.unicode.org/unicode/faq/utf_bom.html#BOM

http://www.opentag.com/xfaq_enc.htm

http://en.wikipedia.org/wiki/Byte_Order_Mark

3.3 V3.0 to V3.1 Gateway Update

3.3.1 Summary of ImprovementsThe benefits of the upgrade are that a NetworkID parameter will be supplied back with delivery statuses.

The new XML element NetworkID provides the network from which the status has been generated where applicable.

This has relevance to standard MTs and to a new type International Mobile Subscriber Identity (IMSI) lookups as follows :3.3.1.1 Standard MTsNOTE the NetworkID value returned is NOT necessarily the network of the mobile phone targeted with an MT.

E.g. a free to end user MT targeted at a Vodafone phone may get delivered via O2

For some delivery receipts a NetworkID is not relevant, in these cases the value will be set to -1

E.g. a WIN internal status. The above issues will either need to be catered for, or for a more clear cut way to be more certain of knowing a phone's actual network would be to structure the service to require an MO or by using an IMSI lookup.

3.3.1.2 International Mobile Subscriber IdentityThis upgrade is necessary for those wishing to make use of the new International Mobile Subscriber Identity (IMSI) service to determine the network of a phone.

Note this capability is intended for background tasks such as cleaning databases rather than being structured into a real time service scenario. This is due to through put limitations.

See the Payload section for a fuller description of this capability.

3.3.2 Changes RequiredThe client should update their delivery receipt receiving website to receive XML compliant with tpbound_receipts_v3p1.dtd rather than the previous definition : tpbound_receipts_v2.dtd.

The client should request an upgrade of a test ServiceID to version 3.1 which should POST TPBound to their upgraded receiving site.Then send some test messages via this ServiceID with delivery receipt requests and test the updated version of their delivery receipt receiving website correctly processes the resultant delivery receipts.

The full DTDs and XML examples are available for download from :




3.3.2.1 DTD relevant extractstpbound_receipts_v2.dtd :

<!ELEMENT SMSRECEIPT (SERVICEID, SOURCE_ADDR, TRANSACTIONID, STATUSID, STATUSDATETIME, TOTALFRAGMENTNO, FRAGMENTID

)>

tpbound_receipts_v3p1.dtd :

<!ELEMENT SMSRECEIPT ( SERVICEID, SOURCE_ADDR, TRANSACTIONID, NETWORKID, STATUSID, STATUSDATETIME, TOTALFRAGMENTNO, FRAGMENTID)>

New element :

<!ELEMENT NETWORKID (#PCDATA)>

3.4 V2.x to V3.0 Gateway Update

3.4.1 Summary of ImprovementsMain Features

Improved ‘Track and Trace’ Delivery Receipt system – note this is only available on Dual ISP Link or leased circuits.

New XML to handle Multipart message delivery receipts Improved security Better handling of Response codes Standardized http encoding format

3.4.2 Changes Required Implement request of new delivery receipts (DR’s) and new status codes –

Section 6.3 Gateway http encoding type is now utf-8 format - Section 4 Update client software to handle new DR XML – Section 6.3 Correctly respond to all MO posts and DR posts – Section 4 Provide list of IP’s for systems that need to connect to WIN gateway V3 – 2.3 Complete the test form (within this section ) Migrate your connection to the Dual ISP link


3.4.3 Raw POST examples of changes

3.4.3.1 Example V3 TPBound HTTP POSTPOST /gateway31/testing/TPBoundCatcher.aspx HTTP/1.1Accept: text/xml, text/html ,*/*Content-Type: application/x-www-form-urlencoded; charset=utf-8Content-Length: 823Expect: 100-continueConnection: CloseHost: localhost:8080

USER=rrr&Password=wwq&TP_XML=%ef%bb%bf%3c%3fxml+version%3d%221.0%22+encoding%3d%22utf-8%22+standalone%3d%22no%22%3f%3e%3c!DOCTYPE+WIN_TPBOUND_MESSAGES+SYSTEM+%22tpbound_messages_v1.dtd%22%3e%3cWIN_TPBOUND_MESSAGES%3e%3cSMSTOTP%3e%3cSOURCE_ADDR%3e%2b447234123456%3c%2fSOURCE_ADDR%3e%3cTEXT%3eBULKTESTH1+Test+1+REP%3d1%3c%2fTEXT%3e%3cWINTRANSACTIONID%3e92637210%3c%2fWINTRANSACTIONID%3e%3cDESTINATION_ADDR%3e82222%3c%2fDESTINATION_ADDR%3e%3cSERVICEID%3e1%3c%2fSERVICEID%3e%3cNETWORKID%3e1%3c%2fNETWORKID%3e%3cARRIVALDATETIME%3e%3cDD%3e8%3c%2fDD%3e%3cMMM%3eAPR%3c%2fMMM%3e%3cYYYY%3e2004%3c%2fYYYY%3e%3cHH%3e11%3c%2fHH%3e%3cMM%3e47%3c%2fMM%3e%3c%2fARRIVALDATETIME%3e%3c%2fSMSTOTP%3e%3c%2fWIN_TPBOUND_MESSAGES%3e&RequestID=4_3634464

3.4.3.2 Example V2 TPBound HTTP POST

POST /gateway31/testing/TPBoundCatcher.aspx HTTP/1.1Accept: text/xml, text/html ,*/*Content-Type: application/x-www-form-urlencoded; charset=iso-8859-1Content-Length: 819Expect: 100-continueConnection: CloseHost: localhost:8080

USER=wed&Password=qwerty&TP_XML=%3c%3fxml+version%3d%221.0%22+encoding%3d%22iso-8859-1%22+standalone%3d%22no%22%3f%3e%3c!DOCTYPE+WIN_TPBOUND_MESSAGES+SYSTEM+%22tpbound_messages_v1.dtd%22%3e%3cWIN_TPBOUND_MESSAGES%3e%3cSMSTOTP%3e%3cSOURCE_ADDR%3e%2b447234123456%3c%2fSOURCE_ADDR%3e%3cTEXT%3eBULKTESTH1+Test+1+REP%3d1%3c%2fTEXT%3e%3cWINTRANSACTIONID%3e92637208%3c%2fWINTRANSACTIONID%3e%3cDESTINATION_ADDR%3e82222%3c%2fDESTINATION_ADDR%3e%3cSERVICEID%3e1%3c%2fSERVICEID%3e%3cNETWORKID%3e1%3c%2fNETWORKID%3e%3cARRIVALDATETIME%3e%3cDD%3e8%3c%2fDD%3e%3cMMM%3eAPR%3c%2fMMM%3e%3cYYYY%3e2004%3c%2fYYYY%3e%3cHH%3e11%3c%2fHH%3e%3cMM%3e33%3c%2fMM%3e%3c%2fARRIVALDATETIME%3e%3c%2fSMSTOTP%3e%3c%2fWIN_TPBOUND_MESSAGES%3e&RequestID=6_3634462


3.4.4 Upgrade from V2 to V3 Test Form

Company Name

Date

Contact Person (Technical)

Contact Telephone

EmailAddress

No Test Instruction Response Pass/Fail1 Request DR Generate a new xml request

with a Receipt request value of 12

Gateway should respond with a 200 OK response

2 Receive WIN DR

Request a DR Gateway should respond with updated xml to which the client can correctly decode

3 DR xml response

Client xml response to good message above should match

Client system generates a good (200 OK) response

4 Response Reference

Client system requests a DR Client system returns unique reference on receipt of DR

5 Request Timeout

Client system requests a DR Client system responds within 40 seconds on receipt of DR.

6 Request timeout repeat

Client system does not respond in time

WIN platform retries message

7 DR Request a DR (type 13) for a contract handset which you know is available

Gateway responds with 3 status message, WIN processing, Delivered to Network and delivered to Phone

8 Network Testing

Send a message to a known good Vodafone handset with DR request type set at 11

Receive good DR status 5

9 Network Testing

Send a message to a known good O2 handset with DR request type set at 11


10 Network Testing

Send a message to a known good Orange handset with DR request type set at 11


11 Network Testing

Send a message to a known good T-Mobile handset with DR request type set at 11


12 Failure Codes

Send message (with DR request) to an invalid MSISDN

Receive back an error. The response will vary by network, but all should fail

13 Failure Codes

Repeat with other failure criteria i.e. set expiry to be very short and handset switched off

Receive back message expiry error, 26 for Operator, 16 for WIN

14 Xml Failure Submit a xml packet which has incorrect parameters as per errors codes 201 to 214Repeat test again as required

Receive back an error code range 201 to 214

Client Tester Test Complete (yes/no)

Date

Please complete and return to [email protected]


mailto:[email protected]

4 HTTP

4.1 OverviewThe diagram below shows the components of this system. It does not attempt to show the resilience or details of the network.

The http communication technique requires the third party to have a web server to which the information can be posted. This is so that mobile users’ generated messages and delivery message receipts can be provided by WIN in an event driven manner.

The number of instructions to WIN (messages, etc) per XML submission is limited to 50 when using HTTP.


4.2 HTTP WINBound Process Description

4.2.1 Third Party Process Description

The third party application shall POST an XML submission to one of the locations :

Standard URL http://gateway3.go2mobile.net:10030/gateway/v3/gateway.aspx

Standard URL (SSL) https://gateway3.go2mobile.net:14430/gateway/v3/gateway.aspx

Dual ISP URL http://bulk.wingateway.com:3003/gateway/v3/gateway.aspxDual ISP URL (SSL) https://bulk.wingateway.com:3443/gateway/v3/gateway.aspx

Note these URLs will only be accessible once an account has been provisioned.

The XML file shall be conformant with the appropriate DTD :

winbound_messages_v1.dtd for sending messages to mobile users

The third party may wish to implement a retry strategy for when valid XML responses from WIN are not received.

To aid third party development there are additional URLs that will respond similarly to the live URL with some differences related to it working against a test database.

Differences : This test database is an overnight snap shot of the live database i.e. today’s gateway

configuration changes will not be present. It will not result in SMS messages being dispatched. It will not result in delivery receipts being dispatched back to customers. This database may not be available from time to time – (when this is the case the

return code in the response of R408 will indicate this). The time for the HTTP Response will be greater than the live URL.

Test URLs :

As above URLs but substitute test.aspx for gateway.aspx


https://bulk.wingateway.com:3443/gateway/v3/gateway.aspx

http://bulk.wingateway.com:3003/gateway/v3/gateway.aspx

https://gateway3.go2mobile.net:14430/gateway/v3/gateway.aspx

https://gateway3.go2mobile.net:14430/gateway/v3/gateway.aspx

http://gateway3.go2mobile.net:10030/gateway/v3/gateway.aspx

http://gateway3.go2mobile.net:10030/gateway/v3/gateway.aspx

4.2.1.1 Method: POST DetailMethod: POSTContent Type: application/x-www-form-urlencoded

When you POST to us you should pass over three parameters (note these are case-sensitive) :

UserPasswordWIN_XMLRequestID

The parameter of "RequestID" which is stored against the submission header record. This is made available so as to provide an opportunity for submissions to be cross referenced between companies. E.g. for referencing submissions that contain invalid XML. RequestID can be thought of as the equivalent of a file name for the FTP interface.

This is to be done in the same way as can be demonstrated by an HTML page available via :http://www.wincast.com/gatewaydemo/smsHTTP/readme.htm

4.2.1.1.1 Encoding TypeThe gateway checks that the encoding type of the HTTP submission is the same as the XML stated encoding type – if it is not the error is recorded and the submission is rejected. The gateway assumes has a default encoding type for HTTP POSTs of utf-8 (Unicode). However it is possible for the default HTTP POST encoding type can be overridden by a client’s POSTs. It is suggested that this is not done.

Utf-8 enables for example the euro symbol to be typed as opposed to included by the use of a hexadecimal value approach ( e.g. &#x00C4 ).

The V3 POST to third parties will be in utf-8 format. This HTTP encoding type is specified within the HTTP header. This provides the benefit of allowing a wider range of characters to be encoded than the previous Latin-1 (ISO-8859-1) encoding type used. E.g. East European, Portugal etc ) Below are examples of the gateway version 2 and version 3 new POSTs (the contained user names, passwords and phone numbers are not valid).



4.2.1.1.2 RAW POST ExamplesFurther examples are available for download within XML_DTD_Files.zip from :


RAW POST Example:

POST /gateway/v2/gateway.aspx:81 HTTP/1.1Accept: */*Accept-Language: en-gbContent-Type: application/x-www-form-urlencodedAccept-Encoding: gzip, deflateContent-Length: 716Connection: Keep-AliveCache-Control: no-cache

User=yourname&Password=yourpassword&RequestID=123&WIN_XML=%3C%3Fxml+version%3D%221.0%22+standalone%3D%22no%22%3F%3E%0D%0A%3C%21DOCTYPE+WIN_DELIVERY_2_SMS+SYSTEM+%22winbound_messages_v1.dtd%22%3E%0D%0A%3CWIN_DELIVERY_2_SMS%3E%0D%0A++%3CSMSMESSAGE%3E%0D%0A++++%3CDESTINATION_ADDR%3E%2B447900570205%3C%2FDESTINATION_ADDR%3E%0D%0A++++%3CTEXT%3E+%C2%A3+%3C%2FTEXT%3E%0D%0A++++%3CTRANSACTIONID%3E333444%3C%2FTRANSACTIONID%3E%0D%0A++++%3CTYPEID%3E2%3C%2FTYPEID%3E%0D%0A++++%3CSERVICEID%3E1%3C%2FSERVICEID%3E%0D%0A++++%3CCOSTID%3E1%3C%2FCOSTID%3E%0D%0A++%3C%2FSMSMESSAGE%3E%0D%0A%0D%0A%3C%2FWIN_DELIVERY_2_SMS%3E%0D%0A%09%09%09%09%09%09%09&OUTPUT=Start+%3A14%3A31.384

4.2.1.2 Method: GETGET support has been implemented but is not supported or encouraged.

Note parameters submitted using HTTP GET must not exceed the standard HTTP GET limit of around 2Kbytes.

With the exception of using GET, the details as per the POST instructions above,

An example implementation of using HTTP GET can be seen via a link at :


The gateway implements receiving the three parameters (login, password, xml) using HTTP GET.

However sending the XML parameter using GET is not officially supported and is not recommended. This is because of encoding issues and size limitations.




4.2.2 WIN Process Description

The XML received will be queued to be actioned.The XML delivered by the third party will receive a response conformant with response_generic_v1.dtd .

Note this response acknowledges acceptance of a request. For detailed ongoing message status tracking a request for delivery receipts must be made within the MT request XML.

4.2.3 Generic Response Code

The generic http request response has been updated to now include the error code 419. This will be returned whenever a connecting client exceeds the maximum simultaneous connections allowed for that client. The current settings are 10 per client

See section 6.4 Generic Response for a detailed description of a response_generic_v1.dtd response including the possible response codes from WIN.

For a response WINBOUND and TPBOUND the XML is to be provided via a content time of text/xml. i.e.

Content Type: text/xmlStatus Code: 200 OK


4.3 HTTP TPBound Process Description

4.3.1 WIN Process DescriptionWIN has improved the performance of its http MO delivery and delivery receipts through to clients. As a result clients will benefit from improved throughput and message trace ability.

When WIN receives messages from mobile users (via the operators) that are configured, either via a unique short code or via a leading keyword, to be forwarded to the third party the information shall be POSTed to the agreed third party hosted URL in the form of tpbound_messages_v1.dtd.

Similarly for messages that were previously sent from the third party, via WIN to the mobile user with delivery receipt requested, WIN will POST the delivery receipt information back to the agreed third party hosted URL in the form of tpbound_receipts_v2.dtd. This will occur when the delivery receipt status reaches Final Status or the third party has explicitly asked for an update of the status by sending WIN a winbound_receiptrequest_v1.dtd message.

If WIN fails to connect to the third party’s web server then WIN will retry at intervals the last being 48 hours after the initial attempt.

4.3.2 Method POST detail

Content Type: application/x-www-form-urlencoded

When we POST to you we pass back three parameters (note these are case-sensitive) :USERPasswordTP_XMLRequestID

The parameter of "RequestID" is unique to the XML being submitted. This is made available so as to provide an opportunity for submissions to be cross referenced between companies. RequestID is in comparison to the FTP interface, the equivalent of a file name.

This is done in the same way as a html page available via :


When a HTTP request is made by WIN or the third party to a HTTP server the login and password that has previously been agreed must be supplied.

The login and password are not contained within the XML.These are used separately to achieve the initial ftp connection when using ftp or supplied a separate parameters when using http. This allows the XML format to be the same for both techniques.

The ChannelID specific logins and passwords may be the same in both directions and match the ftp login and password (if there is an FTP channel present), or may all differ as preferred.

4.3.2.1 RAW POST ExampleFurther examples are available for download within XML_DTD_Files.zip from :





RAW POST Example:

POST /gateway/testing/Catcher_DB_GatewayWEB.aspx HTTP/1.1Accept: text/xml, text/html ,*/*Content-Type: application/x-www-form-urlencoded; charset=utf-8Content-Length: 709Expect: 100-continueConnection: CloseHost: 127.0.0.1:8083

USER=abc&Password=def&TP_XML=%3c%3fxml+version%3d%221.0%22+encoding%3d%22utf-8%22+standalone%3d%22no%22%3f%3e%3c!DOCTYPE+WIN_TPBOUND_MESSAGES+SYSTEM+%22tpbound_messages_v1.dtd%22%3e%3cWIN_TPBOUND_MESSAGES%3e%3cSMSTOTP%3e%3cSOURCE_ADDR%3e%2b447740630138%3c%2fSOURCE_ADDR%3e%3cTEXT%3ebulktesth2%3c%2fTEXT%3e%3cWINTRANSACTIONID%3e357614643%3c%2fWINTRANSACTIONID%3e%3cDESTINATION_ADDR%3e82222%3c%2fDESTINATION_ADDR%3e%3cSERVICEID%3e2%3c%2fSERVICEID%3e%3cNETWORKID%3e2%3c%2fNETWORKID%3e%3cARRIVALDATETIME%3e%3cDD%3e19%3c%2fDD%3e%3cMMM%3eNOV%3c%2fMMM%3e%3cYYYY%3e2004%3c%2fYYYY%3e%3cHH%3e11%3c%2fHH%3e%3cMM%3e4%3c%2fMM%3e%3c%2fARRIVALDATETIME%3e%3c%2fSMSTOTP%3e%3c%2fWIN_TPBOUND_MESSAGES%3e&RequestID=1_5838512

4.3.3 Third Party Process DescriptionThe third party will host a page that can receive, and make appropriate use of, XML data POSTed to it in the format of one of the TPBound DTDs.

e.g. tpbound_messages_v1.dtd and tpbound_receipts_v2.dtd

The third party will send WIN an HTTP Response. The XML inside the response must conform to response_generic_v1.dtd. See section 6.4 DTD Definition : response_generic_v1.dtd for the definition.

This has provision for a request identifier so that client enquiries can be investigated.

The response should be text/xml encoded content as per the example below with a unique REQUESTID for every submission from WIN.

Example: <?xml version="1.0" standalone="no"?><!DOCTYPE SMSRESPONSE SYSTEM "response_generic_v1.dtd"><SMSRESPONSE> <REQUESTID>HTTP_T1_ID679894_R0</REQUESTID></SMSRESPONSE> Note: The request timeout is currently 40 seconds however this is going to be reduced to an eventual target of approx. 10 seconds.

Reponses that do not conform to this xml structure or fail to respond within the 40 second timeout period will result in the re-submission of the payload. Retries will occur at decreasing intervals for up to 48 hours after the first attempt.


5 FTP

5.1 Overview

Communication to WIN is achieved by files being copied to WIN hosted FTP servers.Communication to the Third Party is achieved by files being copied to the Third Party hosted FTP servers.

When the third party wishes to send some SMS messages to some customers this will be achieved by transferring files to WIN into the WINBound directory. The content of each file must be a well-formed and valid XML document. The document must conform to the winbound_messages_v1.dtd as detailed within the final section of this document.

The ‘WIN FTP Server’ will externally appear as a single IP address. However internal to WIN, so as to achieve redundancy and performance, this is in fact a number of load balanced servers. This approach could be considered by third parties to enhance their FTP TPBound receiving capability.

So as to achieve batching of items in to fewer files a slightly greater delay may be incurred with TPBound information when compared with the HTTP service.


5.1.1 Maximum file sizeThe number of instructions to WIN or from WIN (messages, delivery receipt requests etc ) per XML file is limited for FTP to 500Kbytes. Files sent to WIN that exceed this limit will be rejected.

This 500Kbyte document limit is approximately : Either 8500 messages if same message content for each target phone number

(i.e. multiple DESTINATION_ADDR elements). Or 1200 messages if different message content for each target phone number

(i.e. multiple SMSMESSAGE elements).

Similarly, files dispatched by WIN may be up to a maximum of this size.

5.1.2 Folder structureFor WIN bound files the files will be placed in :

<WINHostedFTPRootDir>/winbound After being processed by WIN these files will be moved to subdirectories* of either :

<WINHostedFTPRootDir>/winbound/processedOr : <WINHostedFTPRootDir>/winbound/rejected

The subdirectories* are named D1 to D7 for the days of the week (1 being Sunday). Each directory is emptied prior to being used.

For Third Party bound files the files will be placed in :

<TPHostedFTPRootDir>/tpboundAfter being processed by the third party these files will be moved to subdirectories* to either :

<TPHostedFTPRootDir>/tpbound/processedOr : <TPHostedFTPRootDir>/tpbound/rejected

The subdirectories* are named D1 to D7 for the days of the week (1 being Sunday). Each directory should be emptied prior to being used.


5.2 FTP WINBound Process Description


5.2.1.1 Establishing A ConnectionThe third party will initiate an FTP connection to the WIN FTP site using the IP Address, port number, username and password provided by WIN. The login will be IP Address restricted.The FTP site will not allow anonymous access.If the connection is not established the third party will follow the defined retry strategy.5.2.1.2 Life Time Of The ConnectionThe third party may hold the connection open for the transfer of more than a single file. The third party may hold the connection open but idle in anticipation of a further file transfer. WIN may close the connection after an idle time of 15 minutes. If the third party attempts to use a connection that has been closed by WIN they will attempt to re-establish the connection.5.2.1.3 File TransferFiles will be transferred (e.g. by using the FTP PUT command).All files will be transferred in ASCII format. If a file transfer fails, The third party will follow the defined retry strategy. 5.2.1.3.1 File Naming conventionWhen files have been processed by WIN they will be copied into either the /processed/Dx or /rejected/Dx (where x = 1 (Sunday) .. 7 (Saturday); y = 00 to 23) directory where they will be concatenated into larger files.

Files presented to WIN must have unique names that are no longer than 50 characters.Therefore the following it is suggested for a file naming convention :

<ClientIP>_<Host Pid>_<yy><mm><dd>_<hh><mn><ss>_<nnnn>_<ServiceID>.tmp

Where :

ClientIP IP address of the Client server on the third party network no NAT(Network Address Translation). In hexadecimal format with no punctuation

Host Pid Process identifier on the client host system (a decimal integer)Dd Day of month (01-31)Mm Month of year (01-12)Yy Last two digits of year (00-99)Hh Hours of creation time (00-23)Mn Minutes of creation time (00-59)Ss Seconds of creation time (00-59)Nnnn Sequence number (00000-9999)ServiceID The Identifier for the third party application

e.g. 123123023004_123_050726_175320_1234_4.tmpThis naming convention is only a suggestion –any scheme that can guarantee unique file names may be adopted, however some further information may help any future trouble shooting. E.g. If a unique identify number from a database is available then the file name could be as simple as :

><nnnn>.tmp

Once it has been successfully transferred a file will be renamed (e.g. using the FTP RENAME command). The new name of the file will be identical to that described above with the exception that the file extension will be changed from .TMP to .XML. If a file rename fails, The third party will follow the retry strategy defined in the following section .


5.2.1.4 Retry StrategyOn failure of any of the activities describe above the third party will retry as follows:

One immediate Retry- followed by One retry after a 5 second pause - followed by One retry after a 10 second pause - followed by One Retry after a 20 second pause - followed by One Retry after a 60 second pause - followed by One Retry after a 360 second pause - followed by

Should this still prove to be unsuccessful then the support procedures will be initiated using the error reporting mechanism.5.2.1.5 File ContentThe content of the file will be a well-formed and valid XML document. The document will conform to the winbound_messages_v1.dtd.

A large number of messages within one file will be processed faster than the same number of messages in a number of files.

However files that exceed a size of 500 Kbytes will be rejected. 5.2.1.6 Heart Beat Messages - OptionalIf required, a heartbeat message can be set against individual ServiceIDs. Each service application will optionally be expected to dispatch a message every 15 (configurable) minutes. If there is no normal message request activity within this period of time then a dummy ‘heart beat’ message is to be sent, indicated by Type=1. The heartbeat mechanism will be implemented on a per ServiceID basis following prior agreement with WIN.

5.2.1.7 Error ReportingThis section pertains to individual sender ServiceID applications. As such this section contains a suggested strategy which is not compulsorily or mandated by WIN.

The error reporting mechanism for the third party will utilize email. An email will be sent to previously agreed email addresses (e.g. WIN operations). Emails will be generated for the following reasons.

This message will have the subject of :“WIN INTEFACE PRIMARY SITE FAILURE - <Third Party Name>”

The body will contain the filename and the function. The function will be one of: CONNECT – failed to connect PUT – failed to put a file RENAME – failed to rename file



5.2.2.1 WINBound file detectionThe application has ‘File Events’ registered to each of the \winbound directories. When one of these are triggered, any XML files in the directory are processed. In the unlikely situation that the event is not detected there is a further periodic check for inbound XML every ~3 seconds.5.2.2.2 WINBound file movement and deletionIf the XML can not be parsed it is moved into the /rejected directory.If the XML can be parsed it is moved into the /processed/Dx (where x = 1 (Sunday) .. 7 (Saturday); y = 00 to 23) directory after all SMSMESSAGE elements have been processed.

The subdirectories* are named D1 to D7 for the days of the week. Each directory will be emptied prior to being used.

The files that build up in /WINBound/rejected/Dx (where x = 1 (Sunday) .. 7 (Saturday); y = 00 to 23) should be inspected by the third party to identify the issue that causes the XML to be invalid and then deleted by the third party. The XML received will be queued to be actioned.

The XML delivered by the third party will receive a response conformant with response_generic_v1.dtd which provides a request identifier.

The XML delivered by the third party will receive a response in a file placed in the ftp subdirectory <WINHostedFTPRootDir>\tpbound conformant with response_generic_v1.dtd which identifies which of the above scenarios occurred. The file name will be built up of a receipt ID and the name of the received file name :

Response_<RequestID>_<name of the received file name>

5.2.2.3 WINBound file processingEach SMSMESSAGE element is checked to contain values that have been agreed. i.e. They must correspond to one row in the ‘Allowed Combinations’ of values table.

A check will be performed to ensure that expired messages are not processed.This will consist of checking :

IF (EXPIRYTIME element is not provided) // The offset amount is configurable per ServiceID. // Unless otherwise instructed by the third party it will be 1 day. SET EXPIRYTIME = 1 dayENDIF

IF (DELIVERYDATETIME element is not provided) SET DELIVERYDATETIME = The arrival time of the XML // (this time is either the FTP file timestamp // or when delivered to WIN HTTP site) Message is processedENDIF

IF (CurrentDateTime < DELIVERYDATETIME + EXPIRYTIME ) Message is processedENDIF

It is expected that the messages will only not be processed because of this if the DELIVERYDATETIME is set more than the EXPIRYTIME into the past by the third party.


5.3 FTP TPBound Process Description


Communication to the Third Party is achieved by files being copied to the Third Party hosted FTP servers.

The WIN platform shall place on to the Third Party’s FTP server the XML files in the subdirectory \tpbound down from the login root ftp directory.

The XML files shall conform to one of the TPBound XML DTDs defined at the end of this document.E.g. The DTD tpbound_messages_v1.dtd . (These may contain a number of SMS messages received from customers.)


The third party application shall copy, or open and parse in location, the XML file in the \tpbound directory down from the root ftp directory.

Once this has been done it is the responsibility of the third party to copy the file to a \tpbound\processed subdirectory. In the unlikely event that the file can not be parsed it shall be copied to the \tpbound\rejected subdirectory.


6 XML Definitions and ExamplesFor efficiency of processing the XML received store a local copy of the DTDs for validation purposes.

The DTDs and example XML files contained in this section are available for download via :


Note part of the XML industry standard DTD definition syntax is :

W hen a parameter has a + symbol following it one or more of those parameters must be present in the XML.

When a parameter has a ? symbol following it zero or one instances of that parameter must be present in the XML.

When a parameter has neither of these symbols following it then one instance of that parameter must be present in the XML.

The order of the elements within the XML is significant in achieving validation of XML against a DTD.

XML lexical elements within the PCDATA fields are not allowed.

Note the DTD definitions include essential information in comments describing the use of the various elements and attributes.



6.1 WINBound : messages to send to mobiles

6.1.1 DTD Definition : winbound_messages_v1.dtdFile name = winbound_messages_v1.dtd

<!ELEMENT WIN_DELIVERY_2_SMS (SMSMESSAGE+)>

<!ELEMENT SMSMESSAGE ( DESTINATION_ADDR+, TEXT+, TRANSACTIONID, TYPEID, SERVICEID, COSTID, CREATIONDATETIME?, NETWORKID?, DELIVERYDATETIME?, DELIVERYRECEIPT?, EXPIRYTIME?, PRIORITY?, SOURCE_ADDR?, FLASH?, BLINK?, REMOVE?, WINTRANSACTIONID?)>



<!ELEMENT DESTINATION_ADDR (#PCDATA)> 

<!ELEMENT TEXT (#PCDATA)> 

<!ELEMENT TRANSACTIONID (#PCDATA)> 

<!ELEMENT TYPEID (#PCDATA)>

<!ELEMENT SERVICEID (#PCDATA)> 

<!ELEMENT COSTID (#PCDATA)> 

<!ELEMENT CREATIONDATETIME (DD, MMM, YYYY, HH, MM)>  <!ELEMENT NETWORKID (#PCDATA)> <!-- Messages that are to result in a charge to the end user must be dispatched using the same network as that of the target phone.

For target phones that have previously been sent in a message (or IMSI look up) WIN will have a record of the phones network.

This element value is only used when third party decide to take responsibility of validating the network of customers.

In the circumstances of one of the following : WIN taking responsibility for validating the network (configuration setting) The NetworkID element not being present The NetworkID element not being set to 0 The following logic will be used to determine the network : 1) Look for a record of the phone number's network on the WIN database. If not found then ... 2) Look for a match for the prefix of the phone number to an OFTEL lookup. If not found then ... 3) If the message request is for a reverse billed message then block message.

(Free messages will never be blocked.)

For certain overseas networks an alternative approach is required for premium rate traffic : A CostID must be used with Single Network Routing to the appropriate NetworkID : NetworkID German 87 Irish 50 etc - please request further information for an up to date list. -->

<!ELEMENT DELIVERYRECEIPT (#PCDATA)> 

<!ELEMENT DELIVERYDATETIME (DD, MMM, YYYY, HH, MM)> <!ELEMENT EXPIRYTIME (HH, MM)> <!ELEMENT DD (#PCDATA)> <!ELEMENT MMM (#PCDATA)> <!ELEMENT YYYY (#PCDATA)> <!ELEMENT HH (#PCDATA)> <!ELEMENT MM (#PCDATA)> 

<!ELEMENT PRIORITY (#PCDATA)> 

<!ELEMENT SOURCE_ADDR (#PCDATA)>  <!ELEMENT FLASH (#PCDATA)>  <!ELEMENT BLINK (#PCDATA)>  <!ELEMENT REMOVE (#PCDATA)>

<!ELEMENT WINTRANSACTIONID (#PCDATA)>

6.1.2 XML Example<?xml version="1.0" standalone="no"?><!DOCTYPE WIN_DELIVERY_2_SMS SYSTEM "winbound_messages_v1.dtd">

<WIN_DELIVERY_2_SMS>

  <SMSMESSAGE> <DESTINATION_ADDR>+447940123456</DESTINATION_ADDR> <TEXT>Hello World</TEXT> <TRANSACTIONID>333444</TRANSACTIONID> <TYPEID>2</TYPEID> <SERVICEID>1</SERVICEID> <COSTID>1</COSTID> </SMSMESSAGE>

 <SMSMESSAGE> <DESTINATION_ADDR>+447234123456</DESTINATION_ADDR> <TEXT>Hello World 2</TEXT> <TRANSACTIONID>2222</TRANSACTIONID> <TYPEID>2</TYPEID> <SERVICEID>1</SERVICEID> <COSTID>1</COSTID> <DELIVERYRECEIPT>13</DELIVERYRECEIPT> <WINTRANSACTIONID>22222</WINTRANSACTIONID> </SMSMESSAGE>

 <SMSMESSAGE> <DESTINATION_ADDR>+447940123456</DESTINATION_ADDR> <TEXT><Hello World</TEXT> <TRANSACTIONID>333445</TRANSACTIONID> <TYPEID>2</TYPEID> <SERVICEID>1</SERVICEID> <COSTID>1</COSTID> <CREATIONDATETIME> <DD>21</DD><MMM>MAY</MMM><YYYY>2005</YYYY> <HH>13</HH><MM>00</MM> </CREATIONDATETIME> <NETWORKID>1</NETWORKID> <DELIVERYDATETIME> <DD>21</DD><MMM>MAY</MMM><YYYY>2005</YYYY> <HH>20</HH><MM>30</MM> </DELIVERYDATETIME> <DELIVERYRECEIPT>12</DELIVERYRECEIPT> <EXPIRYTIME> <HH>1</HH><MM>30</MM> </EXPIRYTIME> <SOURCE_ADDR>FATHERXMAS</SOURCE_ADDR> <WINTRANSACTIONID>22222</WINTRANSACTIONID> </SMSMESSAGE>

 <SMSMESSAGE> <DESTINATION_ADDR>+447234123451</DESTINATION_ADDR> <DESTINATION_ADDR>+447234123452</DESTINATION_ADDR> <DESTINATION_ADDR>+447234123453</DESTINATION_ADDR> <DESTINATION_ADDR>+447234123454</DESTINATION_ADDR> <DESTINATION_ADDR>+447234123455</DESTINATION_ADDR> <TEXT>message to all on distribution list</TEXT> <TRANSACTIONID>2222</TRANSACTIONID> <TYPEID>2</TYPEID> <SERVICEID>1</SERVICEID> <COSTID>1</COSTID> </SMSMESSAGE>

</WIN_DELIVERY_2_SMS>

6.2 TPBound : Messages received from customers

6.2.1 DTD Definition : tpbound_messages_v1.dtdFile name = tpbound_messages_v1.dtd

<!ELEMENT WIN_TPBOUND_MESSAGES (SMSTOTP+)>

<!ELEMENT SMSTOTP (SOURCE_ADDR, TEXT, WINTRANSACTIONID, DESTINATION_ADDR, SERVICEID, NETWORKID, ARRIVALDATETIME, LOCATION? )>

<!ELEMENT DESTINATION_ADDR (#PCDATA)> <!ELEMENT SOURCE_ADDR (#PCDATA)> <!ELEMENT TEXT (#PCDATA)> <!ELEMENT WINTRANSACTIONID (#PCDATA)> <!ELEMENT SERVICEID (#PCDATA)> <!ELEMENT NETWORKID (#PCDATA)>

<!ELEMENT ARRIVALDATETIME (DD, MMM, YYYY, HH, MM)> <!ELEMENT DD (#PCDATA)> <!ELEMENT MMM (#PCDATA)> <!ELEMENT YYYY (#PCDATA)> <!ELEMENT HH (#PCDATA)> <!ELEMENT MM (#PCDATA)> <!ELEMENT LOCATION (#PCDATA)> 

6.2.2 XML Example<?xml version="1.0" standalone="no"?><!DOCTYPE WIN_TPBOUND_MESSAGES SYSTEM "tpbound_messages_v1.dtd">

<WIN_TPBOUND_MESSAGES>

<SMSTOTP> <SOURCE_ADDR>+447940123456</SOURCE_ADDR> <TEXT>Hello World 3</TEXT> <WINTRANSACTIONID>1_333445</WINTRANSACTIONID> <DESTINATION_ADDR>8222</DESTINATION_ADDR> <SERVICEID>1</SERVICEID> <NETWORKID>1</NETWORKID> <ARRIVALDATETIME> <DD>21</DD><MMM>MAY</MMM><YYYY>2005</YYYY> <HH>20</HH><MM>30</MM> </ARRIVALDATETIME> </SMSTOTP> <SMSTOTP> <SOURCE_ADDR>+447234123456</SOURCE_ADDR> <TEXT>Hello World 3</TEXT> <WINTRANSACTIONID>333447</WINTRANSACTIONID> <DESTINATION_ADDR>8222</DESTINATION_ADDR> <SERVICEID>1</SERVICEID> <NETWORKID>1</NETWORKID> <ARRIVALDATETIME> <DD>21</DD><MMM>MAY</MMM><YYYY>2005</YYYY> <HH>20</HH><MM>31</MM> </ARRIVALDATETIME> </SMSTOTP>

</WIN_TPBOUND_MESSAGES>

6.3 TPBound : Delivery Receipts

6.3.1 DTD Definition : tpbound_receipts_v3p1.dtdFile name = tpbound_receipts_v3p1.dtd

<!ELEMENT WIN_RECEIPTS (SMSRECEIPT+)>

<!ELEMENT SMSRECEIPT (SERVICEID, SOURCE_ADDR, TRANSACTIONID,

NETWORKID, STATUSID, STATUSDATETIME, TOTALFRAGMENTNO, FRAGMENTID

)>

<!ELEMENT SERVICEID (#PCDATA)> 

<!ELEMENT SOURCE_ADDR (#PCDATA)> 

<!ELEMENT TRANSACTIONID (#PCDATA)> 

<!ELEMENT NETWORKID (#PCDATA)> 

<!ELEMENT STATUSID (#PCDATA)> 

<!ELEMENT STATUSDATETIME (DD, MMM, YYYY, HH, MM, SS)> 

<!ELEMENT DD (#PCDATA)>  <!ELEMENT MMM (#PCDATA)>  <!ELEMENT YYYY (#PCDATA)>  <!ELEMENT HH (#PCDATA)>  <!ELEMENT MM (#PCDATA)>  <!ELEMENT SS (#PCDATA)>

<!ELEMENT TOTALFRAGMENTNO (#PCDATA)> 

<!ELEMENT FRAGMENTID (#PCDATA)>

6.3.2 XML Example<?xml version="1.0" standalone="no"?><!DOCTYPE WIN_RECEIPTS SYSTEM "tpbound_receipts_v3p1.dtd" [ ]>

<WIN_RECEIPTS>

<SMSRECEIPT> <SERVICEID>1</SERVICEID> <SOURCE_ADDR>+447740630138</SOURCE_ADDR> <TRANSACTIONID>2222</TRANSACTIONID> <NETWORKID>3</NETWORKID> <STATUSID>26</STATUSID> <STATUSDATETIME><DD>11</DD><MMM>MAY</MMM><YYYY>2005</YYYY><HH>15</HH><MM>46</MM><SS>46</SS></STATUSDATETIME> <TOTALFRAGMENTNO>1</TOTALFRAGMENTNO> <FRAGMENTID>1</FRAGMENTID></SMSRECEIPT>



<SMSRECEIPT> <SERVICEID>1</SERVICEID> <SOURCE_ADDR>+447740630238</SOURCE_ADDR> <TRANSACTIONID>2224</TRANSACTIONID> <NETWORKID>555</NETWORKID> <STATUSID>26</STATUSID> <STATUSDATETIME> <DD>11</DD><MMM>MAY</MMM><YYYY>2005</YYYY><HH>15</HH><MM>50</MM><SS>46</SS> </STATUSDATETIME> <TOTALFRAGMENTNO>3</TOTALFRAGMENTNO> <FRAGMENTID>2</FRAGMENTID></SMSRECEIPT>

</WIN_RECEIPTS>

6.3.3 Gateway StatusID ValuesStatusIDs outside the initial 2052 to 2069 are received by V2 gateway customers.StatusIDs below 1000 are received by V3 gateway customers.

Gateway StatusID

Final Status

Client Retry

Retry Strategy

Error Code Description

2052 Yes Yes A Failed @ WIN2053 Yes No NA Delivered To Network (final)2054 Yes No NA Delivered To Phone2055 Yes Yes A Failed @ Operator2068 No NA NA WIN Processing2069 No NA NA Operator is Retrying Message

1 No NA NA WIN Processing2 Yes No NA Delivered To Network (final)3 No NA NA Delivered To Network (intermediate)4 No NA NA Operator is Retrying Message5 Yes No NA Delivered To Phone6 Yes Yes A Failed @ Operator7 Yes Yes A Failed @ WIN8 Yes No NA Pulled by

handset MMS

WIN have delivered the MMS payload to the network's WAP Gateway. (There is still the final stage of the phone downloading the content from the network's WAP Gateway - this is not visible, i.e. reportable, by WIN.)

9 Yes No NA Delivered to network MMS10 Yes No NA Formatting Error SMS too long11 Yes No NA Unknown Subscriber12* Yes Yes B or

specialInsufficient Credit

3 : Retry should be 5mins, 2hrs, 24hrs, 48 hrs, 7 days, then every 7 days up to 30 days

T Mobile : Retry should be 3hrs, 5hrs, 12 hrs, 24 hrs

13 Yes No NA Subscriber Barred14 Yes No NA Incorrect Billing15 Yes No NA Invalid Originator16 Yes Yes A Message Expired @ WIN17 Yes No NA Invalid Expiry Value18 Yes No NA Duplicated Message19* Yes Yes C O2 only.

Meaning is one of :

Out of Credit. Billing System Busy.Prepay message already In Pipe.

In pipe = an earlier request for a prepay MT is en-route within O2 to be delivered to the phone. Subsequent MT requests are rejected.

It would be beneficial to have a distinctive status code for out of credit.WIN are pressing O2 for this.

20 Yes No NA Zero Length Data21 Yes No NA Binary Too Long22 Yes No NA Binary Incorrect Format23 Yes Yes B SIM Full24 Yes No NA Absent Subscriber25 Yes Yes A Error in Delivery To Operator26 Yes Yes A Message Expired @ Operator27 Yes No NA Not defined - Status Unknown99* Yes No NA Delivery A final delivery receipt has not been issued by


receipt timeout

the Network Operator for the SMS.WIN has timed out waiting for this and has therefore issued this final status.

201 Yes No NA Invalid Login202 Yes No NA Invalid XML203 Yes No NA XML/Envelope encoding mismatch204 Yes No NA Unexpected XML Definition206 Yes No NA Maximum File Size Exceeded208 Yes No NA Invalid DESTINATION_ADDR209 Yes No NA Invalid TYPEID210 Yes No NA Invalid ServiceID for used login211 Yes No NA Invalid COSTID213 Yes No NA Invalid NETWORKID214 Yes No NA Invalid PRIORITY215 Yes No NA Customer & OFTEL Network lookup failed217 Yes No NA DELIVERYDATETIME is too far off (max 7 days)252 Yes No NA RING TONE :missing phone code253 Yes No NA NOKIA OPERATOR LOGO :missing or invalid Operator Logo

Network254 Yes No NA NOKIA BOOKMARK :missing bookmark name255 Yes No NA NOKIA BOOKMARK : URL > 50 characters256 Yes No NA Reverse Billed Traffic Not Supported for this Type of Traffic257 Yes No NA RING TONE :empty RTTL258 Yes No NA RING TONE: phone model is not supported259 Yes No NA New receipting API not yet supported260 Yes No NA Information Only – Message has been fragmented261 Yes No NA Barred at WIN – specific phone is barred262 Yes No NA Barred at WIN – non-phone specific reason

e.g. short code263 Yes No NA Delivered To SMPP system (final)264 Yes No NA IMSI Lookup - System Error265 Yes No NA IMSI Lookup - Success266 Yes No NA IMSI Lookup - Failure267 Yes Yes C IMSI Lookup - Absent Subscriber

A retry may be of benefit however there may be a charge for this.

Please note that not all status codes are supported on each network as some networks do not provide as much granularity as others.

Caveat concerning ‘Final Status’ delivery receipts :

Those statuses that are expected to be the last status that will be received concerning an MT are indicated above as Final Statuses. However, WIN has experienced from some operators that a failed message status (should be Final) can then be followed by a delivered message status

A complete list of the possible NetworkID values The document CommonIdentifiers.DOC contains and is available for download from :




6.3.4 MT Retry StrategyA client might choose to re-submit the same message again following an unsuccessful attempt.This choice should be based upon the nature of the delivery statuses received.The status table in the previous section provides a suggestion as to the retry strategy :

Retry Strategy

Time Interval

A 5 Mins, 15 Mins, 30 Mins, 1 HourB 3 Hours, 5 Hours, 12 Hours, 24 HoursC 15 Mins, 30 Mins, 3 Hours, 12 Hours

More than 4 attempts to send the same message to the same phone is not considered acceptable behaviour by the operators, and thus also by WIN.

The times are listed as the interval time between each message attempt and have been defined with information provided by the network operators.

e.g. For out of credit on retry strategy B, wait 3hours and resubmit, then if still failed wait a further 5 hours and resubmit again etc.


6.4 Generic Response

6.4.1 DTD Definition : response_generic_v1.dtdFile name = response_generic_v1.dtd

<!ELEMENT SMSRESPONSE ( REQUESTID )>



<!ELEMENT REQUESTID (#PCDATA)> <!-- max 50 characters

REQUESTID format when WIN are generating an SMSRESPONSE :

HTTP_Tx_IDy_Rz

where : x = table number (32bit int) y = Identity column on WIN database ( x and y uniquely identifies the submission to WIN) (32 bit integer) z = 'R' Return Status Code (32bit int) Note that x, y and z may be one or more digits.

'R' Return Codes :

301 = Invalid XML 302 = Invalid Login 406 = Encoding Types unmatched 407 = DTD or XML Schema not known 409 = Invalid HTTP Content Type, should start with "application/x-www-form-urlencoded" 410 = DTD not found. 416 = WIN website Internal - exSQL 417 = WIN website Internal - exGen 418 = WIN website Internal - exUA 419 = Max_no_of_simultaneous_connections_exceeded (HTTP connection limit is 10) 423 = Configuration Database not currently available 424 = Target Database not currently available 425 = Configuration Database connection string invalid format 426 = Target Database connection string invalid format more error codes may be added in the future 2000 to 3000 = Additional codes reserved for clients to assign for scenarios that do not match those above.

e.g. HTTP_T1_ID679894_R0 e.g. HTTP_T1_ID0_R302

When the client generates an SMSRESPONSE the value of REQUESTID is not parsed by WIN but only stored as a string. It is suggested that clients follow a similar structure to that which WIN produces when a MT request is made but it is not a requirement to do so. The combination of x and y should aim to help in correlating the data recorded at WIN concerning a HTTP POST to a client with that of a client record of events so that an issues can be investigated. e.g. it could be that y = an identity column off a client database table corresponding to a POST of from WIN and x= 1 always if this information is only written to one table.

If you wish to code for scenarios when you would like WIN to retry a POST (e.g. the receiving website detects that the database / queue it needs to write to in not currently available, then for now, it is suggested that you respond with a HTTP 200 code but with no XML in the body.

-->

6.4.2 XML ExampleExample 1 (request accepted) :

<?xml version="1.0" standalone="no"?><!DOCTYPE SMSRESPONSE SYSTEM "response_generic_v1.dtd"><SMSRESPONSE> <REQUESTID>HTTP_T1_ID35479_R0</REQUESTID></SMSRESPONSE>

Example 2 (request not accepted ) :

<?xml version="1.0" standalone="no"?><!DOCTYPE SMSRESPONSE SYSTEM "response_generic_v1.dtd">

<SMSRESPONSE> <REQUESTID>HTTP_T1_ID0_R302</REQUESTID></SMSRESPONSE>


7 Payload typesBy default payload types will be interpreted as plain text.For special payloads WIN will instruct how to make such requests as part of processing a completed application form.

7.1 Plain text PayloadThe TEXT XML element should contain :

Non-binary text characters Maximum size 160 characters.

To send I-MELODY format to Sony Ericsson and Ericsson phones use a standard text payload type.

Those handsets that require mono-phonic ring tones sent to them should not use this payload type.

I-MELODY should be sent to the handsets such as the T68i using a single plain text payload type message. The phone then reformat the text message into a ring tone.

7.2 Binary Payload with User Defined HeaderThe TEXT XML element should contain :

8-bit hex encoded binary . With User Defined Header. Maximum size 140 characters.

The payload is transmitted unchanged to the handset.

This payload type should be used if the destination phone is compliant with EMS (Enhanced Messaging System) as defined by Nokia (at al).

It is not appropriate for any other devices (such as the T68), which do not use the EMS data format

This User Defined Header tells the receiving device how and where to process the remaining data. Part of the UDH is used to indicate fragmented messages so that such messages can be reconstructed in the correct order.

Sending a binary data that includes a User Defined Header to a handset that requires binary formant without the user defined header will result in WIN failing the message (a ‘Failed at WIN’ delivery receipt would be returned). In this scenario the Binary Payload without User Defined Header message type should be used instead.

More Nokia logo and ring tone capability information can be found at :

http://www.wincast.com/winlogosringtones/nokia.asp


http://www.wincast.com/winlogosringtones/nokia.asp

7.3 Binary Payload without User Defined HeaderThe TEXT XML element should contain :

8-bit hex encoded binary . Without a User Defined Header. Maximum size 140 characters.

The payload is transmitted unchanged to the handset.

This is used to transmit binary (i.e. logos, SIRs) to certain handsets that are not EMS (Enhanced Message System) compliant (and therefore do not support UDH). ( e.g. certain handsets Sony-Ericsson and Motorola).

Those handsets that require mono-phonic ring tones sent to them should not use this payload type.

i.e. This payload type better supports those handsets that have problems receiving EMS compliant UDH binary messages, including the Sony-Ericsson T68i, T65, T610 and T800 (but not exclusive to this).

When to use which binary format type :

There are a few guide lines which mainly rely on the client having a working knowledge of the data content he/she is submitting.

1. If the data contains only ASCII characters (i.e. iMelody) then send it as normal text2. If the first byte of the data, when converted to an integer value, is equal or greater

than the length of the entire data block. then do use non-UDH payload type3. If the first byte of the data, when converted to an integer value, is greater than 18

then use non-UDH payload type (18 is a best guess figure for the maximum size of a UDH)

4. If the data is known to contain an EMS compliant UDH then use non-UDH payload type

5. otherwise use UDH payload type 11 ( best estimate)

These are guide lines only and may not apply in every case.


7.4 WAPPush and Bookmarks

When making a WAPPush request the TEXT element needs to contain :

strText = @EncodingType + '|' + @Indication + '|' + @HREF + '|' + @AddEAddress + '|' + @Sender Address

e.g. 1|This is a wap test|http://wap.winwww.net/12345567|1|Win Operationse.g. 1|This is a wap test|http://www.bbc.co.uk/mobile|0|Win Operations

@Encoding Type

Description

1 Service Indicator2 Service Load3 Nokia Bookmark4 Ericsson

Bookmark5 Other bookmark

@Indication is the description what the end user will be able to see on their phone.@HREF is the WAP URL that will be provided to the end user.

@AddEAddress Description0 The @HREF will be requested unaltered.1 The @HREF request will have an additional parameter :

EAddress=EAddress valueThis is the mobile phone number of the customer. E.g. +441234123456This capability is only available when TypeID=5829 (redirect) is requested – see below.

@Sender is an alpha-numeric of up to 40 characters, typically a phone number (long number or short code), from which the WAPPush will appear to have arrived on the end user’s phone.

In order for a WAPPush request to WIN to be recognised as such, one of two specific TypeID element value must be specified in the XML. For these two TypeIDs to be available, a request for WAPPush must be made via the client application form.

TypeID Summary5829 Redirect Recommended

Value5825 No redirect

The ‘Redirect’ approach is recommended as it has a number of advantages : It causes each client request to only result in a one part SMS WAPPush request to

the network operators (thus lower cost and more reliable). It allows WIN the opportunity to append the customer’s phone number to the client

URL that will be requested. Thus it is possible to match up a site request back to the original WAPPush.

Note WAPPush requests to phones are not restricted to being free to end user. Configured CostIDs that are free, or premium rate, may used in conjunction with this capability.

Please note delivery statuses are available for WAPPush for gateway version 3 clients only.Clients requiring receipts that are currently using earlier versions of the gateway will need to upgrade to version 3.


Special NotePlease note the following limitations:

Redirect –This is limited to max 50 characters of text (indication), any additional characters will be removed.

No Redirect - The max combined length of the @Indication + @HREF fields must not be greater than 100 characters. If this length is exceeded then the request will be converted to a ‘redirect’ request.

i.e. No multipart encoding will take place and all requests will generate single part WAP Push messages

7.4.1 Multiple pulls to the same URL

Note if the same URL is sent multiple times to the same phone then some phones may present a cached version of the page.

So if the page contains dynamic content this will be an issue.

A work around is to add a dummy parameter to the URL which could be populated with an incrementing integer.

E.g. Rather than :

http://wap.thelatestnews.comSend :

http://wap.thelatestnews.com?A=23

7.4.2 Just starting out with WAP ?

7.4.2.1 You can download a desktop browser that is capable of viewing wap pagesE.g. From :

http://www.opera.com/http://www.winwap.org/index.html<various phone simulators from operators>

Then perhaps go to http://uk.wap.yahoo.com/ and search for examples of services similar to what you might be considering. In Opera, it is possible to ‘obtain ideas from a page’ use the View menu, then the Source menu item to obtain code. 7.4.2.2 Hello world example : <?xml version="1.0"?><!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN""http://www.wapforum.org/DTD/wml_1.1.xml"><wml><head><meta http-equiv="Cache-Control" content="max-age=3600"/></head> <card id="HelloWorld" ordered="true" title="HelloWorld"><p>Hello World<br/><br/>


http://uk.wap.yahoo.com/

http://www.winwap.org/index.html

http://www.opera.com/

http://wap.thelatestnews.com/

</p></card> </wml> 7.4.2.3 On-line WAP / WML TutorialThere are quite a few of these. For example :

http://www.w3schools.com/wap/default.asp 7.4.2.4 WYSIWYG toolsMany web development tools have ‘what you see is what you get’ components for writing pages.This is taken further by some environments which can, from one page design, serve up different relevant implementations for different client handsets as they contact the web server.


http://www.w3schools.com/wap/default.asp

8 Using WIN Converters For Ring tones, Logos, etc.

8.1 Supported Features and handsetsWIN provides converters for the following contents and makes:

Make Ring tones (mono)

Operator Logos (B/W)

Picture Messages(B/W)

Nokia Bookmarks

Nokia X X X XSagem XMotorola XSony/Ericsson XSiemens XSamsung X X X X

Only a limited number of handsets for each manufacturer is supported. For a complete and exhaustive list of all supported handsets please see the separate spreadsheet ‘Ringtone_and_Logo_compatibitly_list.xls’

8.2 Ring tonesContent is to be provided in RTTTL format. In the TEXT element of the WINBOUND XML please provide the following information:

Handset_Code | RTTTL

where Handset_Code is the ring tone Handset Code shown in the ‘Ringtone_and_Logo_compatibitly_list.xls’ spreadsheet.RTTTL is the RTTTL payload.

E.g. the following TEXT content represents the RTTTL for the ROCKY tunes for a Nokia phone:

N|ROCKY:d=4,o=5,b=100:16e,8g.,2a.,16a,8b.,2e.,16e,8g.,2a.,16a,8b.,1e,16d,16c,8d.,16c,16d,e.,16c,16c,8b4,16b4,16a4,16p,16a4,g.4,8c,8b4,8b4,8b4,8b4,8b4,8b4,16e,8g,2a.

Depending on the handset and length of the RTTTL WIN’s converters may send to the phone up to 3 SMS messages.

8.3 Operator LogosIn the TEXT element of the WINBOUND XML you should insert the following:

Operator_Code | Bitmap

where Operator_Code is:

1 if the handsets is on the Vodafone network 2 if the handsets is on the mmO2 network 3 if the handsets is on the Orange network 4 if the handsets is on the T-Mobile network

and Bitmap is the bitmap representation of the logo in ASCII HEX pair representation. This bitmap should start with the Nokia data header that specifies the size and number of grey shades used – usually 1. The format of the header is as follows:

00 – Indication that what follows is an information field. A hex pair representing the width of the bitmap. HEX48 means 72 pixels and is the

maximum allowed.


A hex pair representing the height of the logo. HEX0E means 14 pixels which the maximum allowed.

A hex pair representing the number of grey shades. HEX01 means 1 grey shade OR only black or white.

For instance 00480E01 means 72 x 14 in black and white.

E.g.2|00480E010FE000800040000000781800FFFFC01C0E0040000000C00022118000010000C00201409010230001E0000100E01F044423F02144003020080007F880A0040C600E0784687801000840382FDDCEFC80C0080260CFDCAEFC31821020638FFDEFFC4C01F000410FDDEEFC84680C0C400FDFFEFC842006286107800078182282

The above is an operator logo with a size of 72 x 14 in black and white destined to a phone on the mmO2 network.

WIN will send up to 2 binary SMS fragments to the phone.

Please read ‘Smart_Messaging_FAQ_v2_0.pdf’ for information on how to calculate bitmaps.

8.4 Picture Messages

The TEXT element should contain the bitmap data – similar format as for Operator Logos above:

Bitmap

Maximum width is 72 pixels and maximum height is 28.

E.g.00481C01DBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bf

WIN will send up to 3 binary SMS fragments to the phone.

8.5 Nokia BookmarkThe TEXT element of the WINBOUND XML should contain the following:

Bookmark_Name | URL

where Bookmark_Name is the name of the bookmark as it will appear on the phone and URL is the URL – starting with ‘http://’.

E.g.

Chess|http://www.games.com/id=12345

The bookmark name is limited to 23 characters and the URL to 50. But the combined size of the bookmark name and URL cannot exceed 63 characters. If the URL requires more than 40 characters then the bookmark name may be truncated.

WIN will always send a single binary SMS message to the phone.


8.6 International Mobile Subscriber Identity (IMSI) Lookup

The International Mobile Subscriber Identity (IMSI) capability enables clients to determine the network of a phone.

8.6.1 Background to product Consumers move to a different mobile network regularly. WIN estimate nearly 3% of the 53m UK mobile subscriber base move network each month. 150,000 of these appear to be migrating to 3 each month. Each user lost to another network causes lost revenues for our clients and additional acquisition costs. WIN also has to handle failed billed messages on our network due to invalid number errors.

A client may build their opt-in list for services by using the MSISDN of the user to communicate with them with offers, subscription content etc. If a user moves network, they will not receive the MT messages anymore, even if the client’s Gateway request asks WIN to route the message. Additionally, mobile networks recycle mobile numbers every 6 months that means a different user could end up receiving the original owner’s messages. This latter issue is particularly of concern from a best practice standpoint.

For MMS services, premium rate billing is only possible using SMS MT. Again this relies upon knowing the correct home network of the user. MMS MO do not arrive with the home network of the user. Using a Network Query IMSI lookup will resolve this.

8.6.2 BenefitsThe primary benefit for a client is information enabling the continuation of dialogues with consumers by updating opt-in user database entries with the latest Home Network for each person; this reduces the need to re-acquire those customers through expensive marketing.

A secondary benefit is to enable premium MMS billing.

A further benefit is reduced traffic of attempts to deliver MT messages to invalid consumer mobile phone numbers.

Finally, this Network Query Gateway should reduce the likelihood of support calls from consumers who have received services on a recycled MSISDN.


8.6.3 How to make use of this serviceIf this service is required is should be specified as part of the Client Configuration.

This will result in a special CostID being assigned as an IMSI lookup flag.

Use this CostID value as part of a standard MT request.

e.g.<?xml version="1.0" standalone="no"?><!DOCTYPE WIN_DELIVERY_2_SMS SYSTEM "winbound_messages_v1.dtd"><WIN_DELIVERY_2_SMS> <SMSMESSAGE>  <DESTINATION_ADDR>+447740630111</DESTINATION_ADDR> <DESTINATION_ADDR>+447740630135</DESTINATION_ADDR> <DESTINATION_ADDR>+447740630159</DESTINATION_ADDR> <TEXT></TEXT>  <TRANSACTIONID>CEL9</TRANSACTIONID>  <TYPEID>2</TYPEID>  <SERVICEID>1</SERVICEID>  <COSTID>10</COSTID>  <DELIVERYRECEIPT>13</DELIVERYRECEIPT> </SMSMESSAGE></WIN_DELIVERY_2_SMS>

As result of this a delivery a status will be returned.

See document section 6 XML Definitions, TPBOUND_RECEIPTS_V3p1.DTD for the definition of a delivery status (possible status values, possible NetworkID values).

Under the circumstance of an Absent Subscriber failure a retry may be of benefit however there may be a charge for this.

9 FAQ

9.1 Generic Technical Questions

9.1.1 I am new to XML or WAP, how can I get up to speed ?There are a number of free tutorials on the internet, for example :

http://www.w3schools.com/

9.1.2 How do I present a pound sign/other symbol in the text message in the XML ?

The recommended technique is to specify the utf-8 encoding type and use an XML library to construct the XML. Simply concatenating strings go create XML is very likely to result in expending time on discussing encoding issues which would otherwise have all been taken care of.

Note if an encoding type is not specified within the xml definition line utf-8 is assumed by default :

<?xml version="1.0"?>

If this approach is adopted then the all characters within the encoding type can be provided in their readable form within the XML.

Symbols not contained within an encoding type are still possible within element values using number character references in any XML document: e.g. hexadecimal € or decimal €.

However the Numeric character references will not be recognized in CDATA marked sections. Therefore CDATA blocks must be ended before the symbol and then started again for the remainder of the text message.

It is therefore best to avoid the use of CDATA and use an XML class library to construct the XML as this will do the hex. encoding and decoding for you.

A reference for the Unicode hexadecimal code values is at :http://www.unicode.org/charts/

However, note besides possible XML encoding issues, there is a further potential issue in that support and integration techniques offered by the operators and handsets varies for different characters. Please enquire if you are having difficulty with a specific symbol however do state the operator & handset make and model please.

Example 1 : Use of chars within encoding type

<?xml version="1.0" encoding="utf-8" standalone="no"?><!DOCTYPE WIN_DELIVERY_2_SMS SYSTEM "winbound_messages_v1.dtd"><WIN_DELIVERY_2_SMS> <SMSMESSAGE> <DESTINATION_ADDR>+447943744176</DESTINATION_ADDR> <TEXT><![CDATA[Hi|one|two|three Play and WIN lots of £££ ü ö ä ß € <Joe> ]]></TEXT> <TRANSACTIONID>2222</TRANSACTIONID> <TYPEID>2</TYPEID> <SERVICEID>1</SERVICEID> <COSTID>1</COSTID> </SMSMESSAGE></WIN_DELIVERY_2_SMS>


http://www.unicode.org/charts/

http://www.w3schools.com/

Example 2 : Use of chars that are outside the encoding type

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?><!DOCTYPE WIN_DELIVERY_2_SMS SYSTEM "winbound_messages_v1.dtd"><WIN_DELIVERY_2_SMS><SMSMESSAGE><DESTINATION_ADDR>+447976722826</DESTINATION_ADDR><TEXT> <![CDATA[This SMS has cost ]]> Ä € £<![CDATA[1. Your account has been credited.]]></TEXT><TRANSACTIONID>1555</TRANSACTIONID><TYPEID>2</TYPEID><SERVICEID>1</SERVICEID><COSTID>1</COSTID></SMSMESSAGE></WIN_DELIVERY_2_SMS>

Note the gateway is moving towards only accepting the utf-8 XML encoding type.For FTP, as of version 3.2, only utf-8 is accepted.

9.1.3 The use of CDATA sections within the TEXT element seems a bit clunky – do I have to use it ?

CDATA does not have to be used.

However, if you are not going to use it and you are not going to use a suitable XML class library, then you do need to understand what it would be doing for you and how else to achieve the same aim.

Everything inside a CDATA section is ignored by the parser.

For example if you place a character like ">" inside an XML element, it will generate an error because the parser interprets it as the end of an element. For example the following is invalid :

<TEXT>Send all your money > me </message>

For this example, to avoid this, you have to replace the ">" character with an entity reference, like this:

<TEXT>Send all your money > me </message>

There are 5 predefined entity references in XML:< < less than> > greater than& & ampersand '

' Apostrophe

" " quotation mark

It is best to avoid the use of CDATA and use an XML class library to construct the XML as this will do the entity and hex. encoding and decoding for you.

9.1.4 The TPBound Messages I receive contain things like > and &#x20AC when the customer did not type this on their phone ?

This is an entity reference and an encoded character in XML. (See the 5 predefined entity references in previous Q&A.)The XML parsing by the third party needs to convert these characters back to what they represent.It is best to avoid trying to manually trying to encode and decode these - the use an XML class library to construct the XML as this will do the entity and hex. encoding and decoding for you.


9.1.5 How do I encode parameters prior to a HTTP POST ?Most development languages have associated with them library functionality to achieve this.However, lower level, unsupported examples in VB and Visual C++ projects can be downloaded from :




9.2 WIN Product Specific

9.2.1 If I where to text somebody and they replied to my text, is there any way of linking the reply to the original text ?

WIN does not provide back a reference to the original MT when passing back the MO message.

WIN get back from the Network operators the MO phone no., target shortcode/longNo and text.

Simplistically the client could match the MO up via its (phone no. + target shortcode/longNo) combination to the last corresponding MT send out via that (phone no. + target shortcode/longNo) combination.

This is problematic when multiple MTs are sent out within a short period of time to the same phone.E.g. 2 MTs sent 2MO received - which MO to pair up with which MT ?

An improved, but still potentially fallible solution is to have more than one shortcode/longNo and cycle MT dispatches to a particular phone no. through them.

E.g. If not expecting to send more than 5 MTs to the same phone within 24hrs then have 5 shortcode or long numbers.

Note although this is a reasonable solution it is still for the client to implement matching up the MOs to MTs and it will only match pairs up correctly most of the time.

An alternative ‘fool proof’ solution could be to insist upon the customers providing back a reference as part of the MO text content that they received in the MT. Many phones include a reply option that includes the original text and therefore clients that use this feature would not need to retype the reference.

9.2.2 How do I request a line break in a text message ?Within the TEXT value use the | symbol.E.g.

<TEXT>one|two|three</TEXT>

9.2.3 Why is a particular not correctly displayed on a phone ?Besides possible XML encoding issues (see earlier section), there is a potential issue in that support and integration techniques offered by the operators and handsets varies for different characters. Please enquire if you are having difficulty with a specific symbol however do state the operator & handset make and model please.

9.2.4 How do I send a message type other than text e.g. a ring tone, logo etc

See main Payload section in this document.9.2.4.1 I want to do the encoding myselfIf you wish to encode ringtones, picture messages, operator logos and bookmarks yourself then all you have to do is ship the ‘encoded’ content to WIN. If the ‘encoded’ content is a simple text message – e.g. ringtones for Sagem phones - then populate the TEXT element of the WINBOUND XML as usual. Make sure the overall length of the message is 160 characters of less.


If the ‘encoded’ content is binary then the client needs to achieve the following : Some ‘encoded’ content do not fit into a single SMS message.

It is the responsibility of the client to produce the required SMS fragments. Add all the required UDH headers Convert all the fragments into ASCII HEX pairs – e.g. 9A3CF4… Place these HEX pairs into the TEXT element of the WINBOUND XML. One <SMSMESSAGE> element is required for each fragment.

WIN will provide you with a means to send your binary fragments via one of WIN’s binary connection. WIN guarantees that the message is shipped unchanged to the phone.

Furthermore the downloadable XML samples include examples :


Please specify on the Application Form that if you require binary UDH 8bits connectivity.

9.2.4.2 I want WIN to do the encoding for meWIN provides converters for a limited sets of handsets. Please see the section about ‘Using WIN Converters For Ringtones, Logos, etc.’ in this document.



9.2.5 QAs on Delivery Receipts

Which Operators offer receipting?All of the standard UK operators can provide delivery receipts.

Do Operators offer receipting for Off-Network Traffic?Yes. e.g. Messages sent to Orange phones via the O2 network delivery receipts (generated by O2) are available.

Does the receipting info available vary for on/off network traffic?The delivery receipts returned from the WIN gateway provide the same information independent of the network from which they were received. What information is available in the receipt (e.g. Delivered/Not Delivered/Delivered Off-Net/Time Delivered/Dead Phone/No Credit/Phone Out Of Coverage/Phone Switched Off/?

See section 6.3

How does this info vary between operators?The delivery receipts returned from the WIN gateway are provided in the form a unified set of StatusID values. However some of the finer granularity StatusIDs are only available from some operators.

What is the reliability? Does this vary between operators?During testing at WIN delivery receipts were experienced to as returning almost immediately to quite some time after the message had arrived on the mobile phone.The operators' order of priority is MT messages, MO messages and lowest of all delivery receipts. It has been noticeable that on some occasions operators hold back returning delivery receipts until, presumably, after a peak on MT messages has subsided.Note operators provide no guarantee that delivery receipts will be returned or how long they will take.Due to the extent of varying platform capacity usage between operators reliability should be expected to vary from time to time from one operator to another as they take on customers, expand their networks, or when special events occur - e.g. an operator specific SMS competition at Xmas.Furthermore since SMS delivery is dependant on the target device (in a cell, switched on, in credit etc) it could be several days before the initial message is actually delivered.

Is receipting available for any message type? (i.e. Reverse billed, free, multi-part messages, business cards)Yes.

I'm assuming that there is no additional cost attached to this?There is currently no charge for the delivery receipts.However the increased workload it will cause on the third party platform and the network operators may need to be considered.
