Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Gateway_InterfaceDefinitionDocument

VIEWS: 31 PAGES: 64

									               WIRELESS INFORMATION NETWORK LTD




                                 WIN Gateway
                                  Version 3.2
                        Interface Definition Document




                                       Revision 3.2.01
                                       rd
                                      3 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 07/08/11
Gateway Interface Definition Document
Document Revision History
             Date   Revisio   Authors        Document Section(s),
                       n                     Comments/Reasons For Change
  30 January          1.0     C. E. Ley      Initial version
     2002
  19 January          1.1     C. E. Ley      Updates
     2002
  28 February         1.2     C. E. Ley      Processed subdirectory updates
     2002
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.1
 14 June 2002         1.6     C. E. Ley      Correction to 2.2.1.1
  11 October          1.7     C. E. Ley      10.7 tpbound_messages_v1.dtd to include a
     2002                                    timestamp, WINTRANSACTIONID added to
                                             winbound_messages_v1.dtd. DELIVERYRECEIPT
                                             possible values changed.
        st
 21 October           1.8     C. E. Ley      Clarifications. No functional changes.
     2002
  th
17 December           1.9     C. E. Ley      XML Encoding changes and a new section (1.5) to
     2002                                    indicate what features within this document have not
                                             been implemented.
        th
 14 January           2.0     C. Perris      Update section 7.1 Web Reporting.
        2003
 24th January         2.1     C. E. Ley      Change of directory structures to include hourly
        2003                                 subdirectories.
      th
 30 January           2.2     C. E. Ley      Description added of new HTTP GET WINBound
        2003                                 capability
     th
 26 February          2.3     C. E. Ley      Changed TPBound FTP to place files on the client‟s
        2003                                 FTP server rather than WIN‟s FTP servers.
 th
6 March 2003          2.4     C. E. Ley      Improved QAs with respect to XML
   st
 1 April 2003         2.5     C. E. Ley      New HTTP Gateway URL and description
  rd
 3 April 2003         2.6     R. Wilson      New Gateway Admin Reporting Screens that make
                                             use of
                                             Template Customer implementation.
   th
19 June 2003          2.7     C. E. Ley      New networks Germany, Ireland and Spain : 8.4.1
                                             and 8.6.1
   th
 18 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.
        th
  04 August           2.9     C.             Added section “9 Using WIN Converters For Ring
    2003                      Perdreau       tones, Logos, etc.” and updated section “10.7
                                             How do I send a message type other than text e.g. a
                                             ring tone, logo etc”
  th
 4 December          2.10     C. E. Ley      Message type 11 and 12
     2003
  nd
 2 April 2004        2.11     J. Rands       Revision to “Feature not yet available”




WIN - Confidential              Page ii of vii                            Printed 07/08/11
Gateway Interface Definition Document
  th
 5 April 2004         3.0      J. Rands       Incorporation of V3 gateway functions
  th
 7 April 2004        3.01      C. E. Ley      General Review esp. new Delivery Receipts
  th
 6 May 2004          3.02      C. E. Ley      Delivery Receipts to include Seconds.
                                              New Delivery Statuses added : 14, 15, 16
  rd
 3 June 2004         3.03      C. E. Ley      Test Key word
  nd
22 Sept 2004         3.04      C. E. Ley      Split „User Guide‟ document into the „Interface
                                              Definition Document‟ and the „Operators‟ Guide‟ to
                                              target different audiences.
       th
 27 October          3.05      C. E. Ley      Additional delivery receipts : Win barred and Phone
        2004                                  barred
     th
 26 January          3.06      C. E. Ley      New implementation of WAPPush section 8.4
        2004
       th
  11 March           3.07      J. Rands       Clarification on test message section 1.95
 31st March          3.08      J. Rands       Add 3# retry scenario
  th
14 April 2005        3.09      C. E. Ley      GatewayDemo references included
   th
20 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       3.1.02     C. E. Ley      Updated structure for delivery receipts v3p1 XML
     2005
  rd
 3 February         3.2.02     C. E. Ley      Multipart messages, FTP 3.2 upgrade, DTD updates
     2006                                     (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 07/08/11
Gateway Interface Definition Document
Table of Contents – Summary
(Sections of to a depth of two displayed only)
1     INTRODUCTION ................................................................................................ 1
    1.1        PURPOSE OF THIS DOCUMENT .................................................................................... 1
    1.2        SCOPE ...................................................................................................................... 1
    1.3        REFERENCED DOCUMENTS ........................................................................................ 1
    1.4        ABBREVIATIONS AND ACRONYMS ............................................................................... 1
    1.5        KEY GATEWAY FEATURES ......................................................................................... 2
    1.6        DOCUMENTED FEATURES NOT CURRENTLY AVAILABLE ................................................ 2
2     SYSTEM OVERVIEW .............................................................................................. 3
    2.1        SUMMARY ................................................................................................................. 3
    2.2        LOGICAL PROTOCOL.................................................................................................. 4
    2.3        COMMUNICATIONS TRANSPORT .................................................................................. 6
    2.4        KEY GATEWAY PARAMETER LIMITS ............................................................................ 6
3     GATEWAY VERSION UPGRADE GUIDE .................................................................... 7
    3.1        GENERAL .................................................................................................................. 7
    3.2        V3.1 TO V3.2 GATEWAY UPDATE ............................................................................... 8
    3.3        V3.0 TO V3.1 GATEWAY UPDATE ............................................................................. 10
    3.4        V2.X TO V3.0 GATEWAY UPDATE ............................................................................. 12
4     HTTP ................................................................................................................ 15
    4.1        OVERVIEW............................................................................................................... 15
    4.2        HTTP WINBOUND PROCESS DESCRIPTION .............................................................. 16
    4.3        HTTP TPBOUND PROCESS DESCRIPTION ................................................................ 20
5     FTP................................................................................................................... 22
    5.1        OVERVIEW............................................................................................................... 22
    5.2        FTP WINBOUND PROCESS DESCRIPTION ................................................................ 24
    5.3        FTP TPBOUND PROCESS DESCRIPTION ................................................................... 27
6     XML DEFINITIONS AND EXAMPLES ...................................................................... 28
    6.1        WINBOUND : MESSAGES TO SEND TO MOBILES ......................................................... 29
    6.2        TPBOUND : MESSAGES RECEIVED FROM CUSTOMERS ............................................... 34
    6.3        TPBOUND : DELIVERY RECEIPTS ............................................................................. 35
    6.4        GENERIC RESPONSE................................................................................................ 41
7     PAYLOAD TYPES ................................................................................................ 43
    7.1        PLAIN TEXT PAYLOAD .............................................................................................. 43
    7.2        BINARY PAYLOAD WITH USER DEFINED HEADER ...................................................... 43
    7.3        BINARY PAYLOAD WITHOUT USER DEFINED HEADER ................................................ 44
    7.4        WAPPUSH AND BOOKMARKS .................................................................................. 45
8     USING WIN CONVERTERS FOR RING TONES, LOGOS, ETC. ................................... 48
    8.1        SUPPORTED FEATURES AND HANDSETS.................................................................... 48
    8.2        RING TONES ............................................................................................................ 48
    8.3        OPERATOR LOGOS .................................................................................................. 48
    8.4        PICTURE MESSAGES ................................................................................................ 49
    8.5        NOKIA BOOKMARK .................................................................................................. 49
    8.6        INTERNATIONAL MOBILE SUBSCRIBER IDENTITY (IMSI) LOOKUP ............................... 50
9     FAQ .................................................................................................................. 52
 9.1      GENERIC TECHNICAL QUESTIONS............................................................................. 52
 9.2      WIN PRODUCT SPECIFIC ......................................................................................... 55
WIN - Confidential              Page iv of vii                                              Printed 07/08/11
Gateway Interface Definition Document
Table of Contents - Detailed
(All Sections displayed)



1     INTRODUCTION ................................................................................................ 1
    1.1         PURPOSE OF THIS DOCUMENT .................................................................................... 1
    1.2         SCOPE ...................................................................................................................... 1
    1.3         REFERENCED DOCUMENTS ........................................................................................ 1
    1.4         ABBREVIATIONS AND ACRONYMS ............................................................................... 1
    1.5         KEY GATEWAY FEATURES ......................................................................................... 2
    1.6         DOCUMENTED FEATURES NOT CURRENTLY AVAILABLE ................................................ 2
2     SYSTEM OVERVIEW .............................................................................................. 3
    2.1         SUMMARY ................................................................................................................. 3
    2.2         LOGICAL PROTOCOL.................................................................................................. 4
      2.2.1     SEND MESSAGES TO MOBILE USERS ........................................................................................... 4
      2.2.2     FORWARD SMS MESSAGES FROM MOBILE USERS TO THIRD PARTY ............................................... 5
      2.2.3     DELIVERY RECEIPTS TO THIRD PARTY ......................................................................................... 5
      2.2.4     PROVIDES ONLINE REPORTS TO THE THIRD PARTY ....................................................................... 5
      2.2.5     TEST KEYWORD....................................................................................................................... 5
    2.3         COMMUNICATIONS TRANSPORT .................................................................................. 6
      2.3.1     GENERAL ................................................................................................................................ 6
    2.4         KEY GATEWAY PARAMETER LIMITS ............................................................................ 6
      2.4.1     IP RESTRICTION ...................................................................................................................... 6

3     GATEWAY VERSION UPGRADE GUIDE .................................................................... 7
    3.1         GENERAL .................................................................................................................. 7
    3.2         V3.1 TO V3.2 GATEWAY UPDATE ............................................................................... 8
      3.2.1     SUMMARY OF IMPROVEMENTS ................................................................................................... 8
      3.2.2     CHANGES REQUIRED – MULTIPART MESSAGES ........................................................................... 8
      3.2.3     CHANGES REQUIRED - FTP CLIENTS ......................................................................................... 9
    3.3         V3.0 TO V3.1 GATEWAY UPDATE ............................................................................. 10
      3.3.1 SUMMARY OF IMPROVEMENTS ................................................................................................. 10
        3.3.1.1 STANDARD MTS ............................................................................................................ 10
        3.3.1.2 INTERNATIONAL MOBILE SUBSCRIBER IDENTITY................................................................ 10
      3.3.2 CHANGES REQUIRED ............................................................................................................. 10
        3.3.2.1 DTD RELEVANT EXTRACTS ............................................................................................. 11
    3.4         V2.X TO V3.0 GATEWAY UPDATE ............................................................................. 12
      3.4.1 SUMMARY OF IMPROVEMENTS ................................................................................................. 12
      3.4.2 CHANGES REQUIRED ............................................................................................................. 12
      3.4.3 RAW POST EXAMPLES OF CHANGES ....................................................................................... 13
        3.4.3.1 EXAMPLE V3 TPBOUND HTTP POST ............................................................................ 13
        3.4.3.2 EXAMPLE V2 TPBOUND HTTP POST ............................................................................ 13
      3.4.4 UPGRADE FROM V2 TO V3 TEST FORM .................................................................................... 14

4     HTTP ................................................................................................................ 15
    4.1         OVERVIEW............................................................................................................... 15
    4.2         HTTP WINBOUND PROCESS DESCRIPTION .............................................................. 16
      4.2.1 THIRD PARTY PROCESS DESCRIPTION ..................................................................................... 16
        4.2.1.1 METHOD: POST DETAIL ................................................................................................ 17
           4.2.1.1.1 ENCODING TYPE ..................................................................................................... 17
           4.2.1.1.2 RAW POST EXAMPLES .......................................................................................... 18
        4.2.1.2 METHOD: GET .............................................................................................................. 18
      4.2.2 WIN PROCESS DESCRIPTION .................................................................................................. 19

WIN - Confidential              Page v of vii                                                                          Printed 07/08/11
Gateway Interface Definition Document
      4.2.3     GENERIC RESPONSE CODE..................................................................................................... 19
    4.3         HTTP TPBOUND PROCESS DESCRIPTION ................................................................ 20
      4.3.1 WIN PROCESS DESCRIPTION .................................................................................................. 20
      4.3.2 METHOD POST DETAIL .......................................................................................................... 20
        4.3.2.1 RAW POST EXAMPLE .................................................................................................. 20
      4.3.3 THIRD PARTY PROCESS DESCRIPTION ..................................................................................... 21

5     FTP................................................................................................................... 22
    5.1         OVERVIEW............................................................................................................... 22
      5.1.1     MAXIMUM FILE SIZE ................................................................................................................ 23
      5.1.2     FOLDER STRUCTURE .............................................................................................................. 23
    5.2         FTP WINBOUND PROCESS DESCRIPTION ................................................................ 24
      5.2.1 THIRD PARTY PROCESS DESCRIPTION ..................................................................................... 24
        5.2.1.1 ESTABLISHING A CONNECTION ....................................................................................... 24
        5.2.1.2 LIFE TIME OF THE CONNECTION...................................................................................... 24
        5.2.1.3 FILE TRANSFER ............................................................................................................. 24
           5.2.1.3.1 FILE NAMING CONVENTION ....................................................................................... 24
        5.2.1.4 RETRY STRATEGY .......................................................................................................... 25
        5.2.1.5 FILE CONTENT ............................................................................................................... 25
        5.2.1.6 HEART BEAT MESSAGES - OPTIONAL .............................................................................. 25
        5.2.1.7 ERROR REPORTING ........................................................................................................ 25
      5.2.2 WIN PROCESS DESCRIPTION .................................................................................................. 26
        5.2.2.1 WINBOUND FILE DETECTION ........................................................................................... 26
        5.2.2.2 WINBOUND FILE MOVEMENT AND DELETION ..................................................................... 26
        5.2.2.3 WINBOUND FILE PROCESSING ........................................................................................ 26
    5.3         FTP TPBOUND PROCESS DESCRIPTION ................................................................... 27
      5.3.1     WIN PROCESS DESCRIPTION .................................................................................................. 27
      5.3.2     THIRD PARTY PROCESS DESCRIPTION ..................................................................................... 27

6     XML DEFINITIONS AND EXAMPLES ...................................................................... 28
    6.1         WINBOUND : MESSAGES TO SEND TO MOBILES ......................................................... 29
      6.1.1     DTD DEFINITION : WINBOUND_MESSAGES_V1.DTD ................................................................... 29
      6.1.2     XML EXAMPLE ...................................................................................................................... 33
    6.2         TPBOUND : MESSAGES RECEIVED FROM CUSTOMERS ............................................... 34
      6.2.1     DTD DEFINITION : TPBOUND_MESSAGES_V1.DTD ..................................................................... 34
      6.2.2     XML EXAMPLE ...................................................................................................................... 34
    6.3         TPBOUND : DELIVERY RECEIPTS ............................................................................. 35
      6.3.1     DTD DEFINITION : TPBOUND_RECEIPTS_V3P1.DTD ................................................................... 35
      6.3.2     XML EXAMPLE ...................................................................................................................... 37
      6.3.3     GATEWAY STATUSID VALUES ................................................................................................. 38
      6.3.4     MT RETRY STRATEGY ............................................................................................................ 40
    6.4         GENERIC RESPONSE................................................................................................ 41
      6.4.1     DTD DEFINITION : RESPONSE_GENERIC_V1.DTD ...................................................................... 41
      6.4.2     XML EXAMPLE ...................................................................................................................... 42

7     PAYLOAD TYPES ................................................................................................ 43
    7.1         PLAIN TEXT PAYLOAD .............................................................................................. 43
    7.2         BINARY PAYLOAD WITH USER DEFINED HEADER ...................................................... 43
    7.3         BINARY PAYLOAD WITHOUT USER DEFINED HEADER ................................................ 44
    7.4         WAPPUSH AND BOOKMARKS .................................................................................. 45
      7.4.1 MULTIPLE PULLS TO THE SAME URL ........................................................................................ 46
      JUST STARTING OUT WITH WAP ? ....................................................................................................... 46
        7.4.1.1 YOU CAN DOWNLOAD A DESKTOP BROWSER THAT IS CAPABLE OF VIEWING WAP PAGES ........ 46
        7.4.1.2 HELLO WORLD EXAMPLE :............................................................................................... 46
        7.4.1.3 ON-LINE WAP / WML TUTORIAL .................................................................................... 47
        7.4.1.4 WYSIWYG TOOLS ........................................................................................................ 47
WIN - Confidential              Page vi of vii                                                                     Printed 07/08/11
Gateway Interface Definition Document
8     USING WIN CONVERTERS FOR RING TONES, LOGOS, ETC. ................................... 48
    8.1          SUPPORTED FEATURES AND HANDSETS.................................................................... 48
    8.2          RING TONES ............................................................................................................ 48
    8.3          OPERATOR LOGOS .................................................................................................. 48
    8.4          PICTURE MESSAGES ................................................................................................ 49
    8.5          NOKIA BOOKMARK .................................................................................................. 49
    8.6          INTERNATIONAL MOBILE SUBSCRIBER IDENTITY (IMSI) LOOKUP ............................... 50
      8.6.1      BACKGROUND TO PRODUCT .................................................................................................... 50
      8.6.2      BENEFITS .............................................................................................................................. 50
      8.6.3      HOW TO MAKE USE OF THIS SERVICE ........................................................................................ 51

9     FAQ .................................................................................................................. 52
    9.1          GENERIC TECHNICAL QUESTIONS............................................................................. 52
      9.1.1   I AM NEW TO XML OR WAP, HOW CAN I GET UP TO SPEED ? ...................................................... 52
      9.1.2   HOW DO I PRESENT A POUND SIGN/OTHER SYMBOL IN THE TEXT MESSAGE IN THE XML ? .............. 52
      9.1.3   THE USE OF CDATA SECTIONS WITHIN THE TEXT ELEMENT SEEMS A BIT CLUNKY – DO I HAVE TO
      USE IT ? ............................................................................................................................................ 53
      9.1.4 THE TPBOUND MESSAGES I RECEIVE CONTAIN THINGS LIKE > AND &#X20AC WHEN THE
      CUSTOMER DID NOT TYPE THIS ON THEIR PHONE ? ................................................................................. 53
      9.1.5 HOW DO I ENCODE PARAMETERS PRIOR TO A HTTP POST ? .................................................... 54
    9.2          WIN PRODUCT SPECIFIC ......................................................................................... 55
      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 ? .......................................................................................................... 55
      9.2.2 HOW DO I REQUEST A LINE BREAK IN A TEXT MESSAGE ? ........................................................... 55
      9.2.3 WHY IS A PARTICULAR NOT CORRECTLY DISPLAYED ON A PHONE ? ............................................. 55
      9.2.4 HOW DO I SEND A MESSAGE TYPE OTHER THAN TEXT E.G. A RING TONE, LOGO ETC ....................... 55
        9.2.4.1 I WANT TO DO THE ENCODING MYSELF .............................................................................. 55
        9.2.4.2 I WANT WIN TO DO THE ENCODING FOR ME ....................................................................... 56
      9.2.5 QAS ON DELIVERY RECEIPTS ................................................................................................. 57




WIN - Confidential              Page vii of vii                                                                            Printed 07/08/11
Gateway Interface Definition Document
1 INTRODUCTION
1.1    Purpose of this Document
The 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                                             Owner
Interface             Specification from client perspective.              WIN Development
Definition
Document
Operator‟s Guide      Guide for online reporting and query                WIN Technical
                      capabilities.                                       Support Group
Client Application    The template for this is the client configuration   WIN Technical
Form                  template document.                                  Support Group
WIN Common            The contains the list of possible NetworkID         WIN Technical
Identifiers           values                                              Support Group



1.4    Abbreviations and Acronyms

Term                 Full Name
SMS                  Short Message Service (commonly known as “text”)
WIN                  Wireless Information Network plc
TP                   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 user
PR                   Premium Rate
SNR                  Single Network Routed
OA Substitution      Originator Address Substitution, sometimes referred to as „spoofing‟
UDH                  User Defined Header
IMSI                 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 07/08/11
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.




WIN - Confidential              Page 2 of 57                           Printed 07/08/11
Gateway Interface Definition Document
2 System Overview

2.1       Summary

                                                             WIN

                                      BulkFTP
                                   (FTP two way)

      Third Party
         ABC




                    Programatic      BulkHttp
                     Channels     (HTTP TPBound)
                      (FTP or
                                                                                              Mobile
                       HTTP)
                                                                                              Users

                                                         Gateway
                    Reports
                    Website
                                                                   Network Operators
                                     Http website
                                  (HTTP WINBound)



      Third Party
         XYZ

                                  WINADMIN website
                                  (client creation and
                                      configuration)




The Message Gateway functionality is as follows:

1. Send messages to mobile users that have been received from the third party
2. Send messages to third party that have been received, via the operators, from mobile
   users
3. 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


WIN - Confidential              Page 3 of 57                                    Printed 07/08/11
Gateway Interface Definition Document
2.2     Logical Protocol
2.2.1    Send messages to mobile users
The 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 content
      third party transaction ID
      third party message type
      third party message service
      reverse billing charge band
      mobile network of recipient
      message delivery time
      message expiry time
      spoofing of „from‟ field
      blinking and flashing
      delivery 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.




WIN - Confidential              Page 4 of 57                              Printed 07/08/11
Gateway Interface Definition Document
2.2.2   Forward SMS messages from mobile users to third party
Messages 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 party
The 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 party
Various 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 Keyword
As 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)
 rd
3 Party Responds = “3rrPartyNameTEST received 02/08/04 13:01.23 sent 02/08/04
13:01.34”
          rd
So if the 3 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




WIN - Confidential              Page 5 of 57                                Printed 07/08/11
Gateway Interface Definition Document
2.3     Communications Transport
2.3.1    General
The 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 Restriction
All 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.




WIN - Confidential              Page 6 of 57                               Printed 07/08/11
Gateway Interface Definition Document
3 Gateway Version Upgrade Guide
3.1       General
Those 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.




WIN - Confidential              Page 7 of 57                                Printed 07/08/11
Gateway Interface Definition Document
3.2     V3.1 to V3.2 Gateway Update
3.2.1    Summary of Improvements
Main 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 capability
           o Multipart MT messages
           o Any new improvements to the HTTP MT receiving website will be
               simultaneously available via the FTP gateway
3.2.2    Changes Required – multipart messages
Clients 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.




WIN - Confidential              Page 8 of 57                                Printed 07/08/11
Gateway Interface Definition Document
3.2.3   Changes Required - FTP clients
The 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_Mark
           Where no BOM is provided utf-8 is assumed. As recommended by :
           http://www.opentag.com/xfaq_enc.htm
           http://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">




WIN - Confidential              Page 9 of 57                                  Printed 07/08/11
Gateway Interface Definition Document
3.3     V3.0 to V3.1 Gateway Update
3.3.1     Summary of Improvements
The 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 MTs
NOTE 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 Identity
This 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 Required
The 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 :

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




WIN - Confidential              Page 10 of 57                              Printed 07/08/11
Gateway Interface Definition Document
3.3.2.1    DTD relevant extracts
tpbound_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)>
 <!--
  The network that generated the status has been generated where applicable.
  Possible values :
  -1 when not applicable e.g. a WIN internal interim status.
   1 = Vodafone
   2 = O2
   3 = Orange
   4 = T Mobile
   etc ...
   See Interface Definition Document for more comprehensive list.

   NOTE this NetworkID 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
 -->




WIN - Confidential              Page 11 of 57                                          Printed 07/08/11
Gateway Interface Definition Document
3.4     V2.x to V3.0 Gateway Update
3.4.1    Summary of Improvements
Main 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




WIN - Confidential              Page 12 of 57                            Printed 07/08/11
Gateway Interface Definition Document
3.4.3     Raw POST examples of changes
3.4.3.1    Example V3 TPBound HTTP POST
POST /gateway31/testing/TPBoundCatcher.aspx HTTP/1.1
Accept: text/xml, text/html ,*/*
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 823
Expect: 100-continue
Connection: Close
Host: localhost:8080

USER=rrr&Password=wwq&TP_XML=%ef%bb%bf%3c%3fxml+version%3d%221.0%22+enc
oding%3d%22utf-
8%22+standalone%3d%22no%22%3f%3e%3c!DOCTYPE+WIN_TPBOUND_MESSAGES+S
YSTEM+%22tpbound_messages_v1.dtd%22%3e%3cWIN_TPBOUND_MESSAGES%3e%3c
SMSTOTP%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%3cNETWOR
KID%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%2fSM
STOTP%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.1
Accept: text/xml, text/html ,*/*
Content-Type: application/x-www-form-urlencoded; charset=iso-8859-1
Content-Length: 819
Expect: 100-continue
Connection: Close
Host: localhost:8080

USER=wed&Password=qwerty&TP_XML=%3c%3fxml+version%3d%221.0%22+encoding%3
d%22iso-8859-
1%22+standalone%3d%22no%22%3f%3e%3c!DOCTYPE+WIN_TPBOUND_MESSAGES+S
YSTEM+%22tpbound_messages_v1.dtd%22%3e%3cWIN_TPBOUND_MESSAGES%3e%3c
SMSTOTP%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%3cNETWOR
KID%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%2fSM
STOTP%3e%3c%2fWIN_TPBOUND_MESSAGES%3e&RequestID=6_3634462




WIN - Confidential              Page 13 of 57                         Printed 07/08/11
Gateway Interface Definition Document
3.4.4     Upgrade from V2 to V3 Test Form


Company                                              Date
Name
Contact                              Contact                        Email
Person                               Telephone                      Address
(Technical)

No      Test          Instruction                       Response                          Pass/Fail
1       Request DR    Generate a new xml request        Gateway should respond with a
                      with a Receipt request value      200 OK response
                      of 12
2       Receive WIN   Request a DR                      Gateway should respond with
        DR                                              updated xml to which the client
                                                        can correctly decode
3       DR xml        Client xml response to good       Client system generates a good
        response      message above should match        (200 OK) response
4       Response      Client system requests a DR       Client system returns unique
        Reference                                       reference on receipt of DR
5       Request       Client system requests a DR       Client system responds within
        Timeout                                         40 seconds on receipt of DR.
6       Request       Client system does not            WIN platform retries message
        timeout       respond in time
        repeat
7       DR            Request a DR (type 13) for a      Gateway responds with 3 status
                      contract handset which you        message, WIN processing,
                      know is available                 Delivered to Network and
                                                        delivered to Phone
8       Network       Send a message to a known         Receive good DR status 5
        Testing       good Vodafone handset with
                      DR request type set at 11
9       Network       Send a message to a known         Receive good DR status 5
        Testing       good O2 handset with DR
                      request type set at 11
10      Network       Send a message to a known         Receive good DR status 5
        Testing       good Orange handset with DR
                      request type set at 11
11      Network       Send a message to a known         Receive good DR status 5
        Testing       good T-Mobile handset with
                      DR request type set at 11
12      Failure       Send message (with DR             Receive back an error. The
        Codes         request) to an invalid MSISDN     response will vary by network,
                                                        but all should fail
13      Failure       Repeat with other failure         Receive back message expiry
        Codes         criteria i.e. set expiry to be    error, 26 for Operator, 16 for
                      very short and handset            WIN
                      switched off
14      Xml Failure   Submit a xml packet which         Receive back an error code
                      has incorrect parameters as       range 201 to 214
                      per errors codes 201 to 214
                      Repeat test again as required

Client Tester                         Test                             Date
                                      Complete
                                      (yes/no)

Please complete and return to tsgadmin@winplc.com
WIN - Confidential              Page 14 of 57                             Printed 07/08/11
Gateway Interface Definition Document
4 HTTP
4.1   Overview
The diagram below shows the components of this system. It does not attempt to show the
resilience or details of the network.


                                                                                  WIN




                        winbound_messages_v1.dtd
                                     1


                         tpbound_messages_v1.dtd
                                     2
      Third Party                                           Http web farm
         ABC                                                (WINBound)




                                                             HTTP Push
                                                             Applications
                       winbound_receiptrequest_v1.dtd        (TPBound)
                                     1

                              pulled or pushed
                         tpbound_receipts_v3p1.dtd
                                       2




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.




WIN - Confidential              Page 15 of 57                               Printed 07/08/11
Gateway Interface Definition Document
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.asp
                          x
Standard URL (SSL)        https://gateway3.go2mobile.net:14430/gateway/v3/gateway.as
                          px
Dual ISP URL              http://bulk.wingateway.com:3003/gateway/v3/gateway.aspx
Dual 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




WIN - Confidential              Page 16 of 57                              Printed 07/08/11
Gateway Interface Definition Document
4.2.1.1     Method: POST Detail
Method: POST
Content Type: application/x-www-form-urlencoded

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

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 Type
The 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).




WIN - Confidential              Page 17 of 57                             Printed 07/08/11
Gateway Interface Definition Document
4.2.1.1.2    RAW POST Examples
Further examples are available for download within XML_DTD_Files.zip from :

          http://www.wincast.com/gatewaydemo/smsHTTP/readme.htm
RAW POST Example:

POST /gateway/v2/gateway.aspx:81 HTTP/1.1
Accept: */*
Accept-Language: en-gb
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Content-Length: 716
Connection: Keep-Alive
Cache-Control: no-cache

User=yourname&Password=yourpassword&RequestID=123&WIN_XML=%3C%3Fxml+versio
n%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++++%3CDESTINA
TION_ADDR%3E%2B447900570205%3C%2FDESTINATION_ADDR%3E%0D%0A++++%3
CTEXT%3E+%C2%A3+%3C%2FTEXT%3E%0D%0A++++%3CTRANSACTIONID%3E3334
44%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: GET
GET 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 :

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


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.




WIN - Confidential              Page 18 of 57                           Printed 07/08/11
Gateway Interface Definition Document
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/xml
Status Code: 200 OK




WIN - Confidential              Page 19 of 57                           Printed 07/08/11
Gateway Interface Definition Document
4.3     HTTP TPBound Process Description
4.3.1     WIN Process Description
WIN 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) :
      USER
      Password
      TP_XML
      RequestID

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 :

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


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 Example
Further examples are available for download within XML_DTD_Files.zip from :

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

WIN - Confidential              Page 20 of 57                                 Printed 07/08/11
Gateway Interface Definition Document
RAW POST Example:

POST /gateway/testing/Catcher_DB_GatewayWEB.aspx HTTP/1.1
Accept: text/xml, text/html ,*/*
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 709
Expect: 100-continue
Connection: Close
Host: 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+S
YSTEM+%22tpbound_messages_v1.dtd%22%3e%3cWIN_TPBOUND_MESSAGES%3e%3c
SMSTOTP%3e%3cSOURCE_ADDR%3e%2b447740630138%3c%2fSOURCE_ADDR%3e%
3cTEXT%3ebulktesth2%3c%2fTEXT%3e%3cWINTRANSACTIONID%3e357614643%3c%2f
WINTRANSACTIONID%3e%3cDESTINATION_ADDR%3e82222%3c%2fDESTINATION_AD
DR%3e%3cSERVICEID%3e2%3c%2fSERVICEID%3e%3cNETWORKID%3e2%3c%2fNET
WORKID%3e%3cARRIVALDATETIME%3e%3cDD%3e19%3c%2fDD%3e%3cMMM%3eNO
V%3c%2fMMM%3e%3cYYYY%3e2004%3c%2fYYYY%3e%3cHH%3e11%3c%2fHH%3e%3
cMM%3e4%3c%2fMM%3e%3c%2fARRIVALDATETIME%3e%3c%2fSMSTOTP%3e%3c%2f
WIN_TPBOUND_MESSAGES%3e&RequestID=1_5838512



4.3.3   Third Party Process Description
The 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.




WIN - Confidential              Page 21 of 57                                Printed 07/08/11
Gateway Interface Definition Document
5 FTP
5.1   Overview

                                                                                 WIN

                                                           BulkFTP
                                   ftp login              (two way)
                                       1
                                       2




                         winbound_messages_v1.dtd
                                       3

                         tpbound_messages_response_
                                   v1.dtd
                                      4
       Third Party
          ABC




                         winbound_receiptrequest_v1.dtd
                                       1

                                pulled or pushed
                            tpbound_receipts_v2.dtd
                                        (2)




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.




WIN - Confidential              Page 22 of 57                              Printed 07/08/11
Gateway Interface Definition Document
5.1.1   Maximum file size
The 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 structure
For 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/processed
Or :    <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>/tpbound
After being processed by the third party these files will be moved to subdirectories* to either :
        <TPHostedFTPRootDir>/tpbound/processed
Or :    <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.




WIN - Confidential              Page 23 of 57                               Printed 07/08/11
Gateway Interface Definition Document
5.2     FTP WINBound Process Description
5.2.1      Third Party Process Description
5.2.1.1     Establishing A Connection
The 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 Connection
The 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 Transfer
Files 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 convention
When 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.tmp
This 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 .
WIN - Confidential              Page 24 of 57                                       Printed 07/08/11
Gateway Interface Definition Document
5.2.1.4   Retry Strategy
On 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 Content
The 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 - Optional
If 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 Reporting
This 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




WIN - Confidential              Page 25 of 57                                 Printed 07/08/11
Gateway Interface Definition Document
5.2.2     WIN Process Description
5.2.2.1    WINBound file detection
The 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 deletion
If 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 processing
Each 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 day
ENDIF

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 processed
ENDIF

IF (CurrentDateTime < DELIVERYDATETIME + EXPIRYTIME )
 Message is processed
ENDIF

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.




WIN - Confidential              Page 26 of 57                                 Printed 07/08/11
Gateway Interface Definition Document
5.3     FTP TPBound Process Description
5.3.1    WIN 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.)

5.3.2    Third Party Process Description

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.




WIN - Confidential              Page 27 of 57                              Printed 07/08/11
Gateway Interface Definition Document
6 XML Definitions and Examples
For 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 :

        http://www.wincast.com/gatewaydemo/smsHTTP/readme.htm
Note part of the XML industry standard DTD definition syntax is :

       When 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.




WIN - Confidential              Page 28 of 57                             Printed 07/08/11
Gateway Interface Definition Document
6.1     WINBound : messages to send to mobiles

6.1.1     DTD Definition : winbound_messages_v1.dtd
File 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?
)>


 <!-- General Comments
 If WIN receive a valid XML document that contains an unexpected value
 in any of the elements then the SMS will not be sent out.
 E.g. a CostID that is not on the application/configuration Form.
 Those clients that request V3 delivery receipts will receive
 status updates to this effect.
 -->


<!ELEMENT DESTINATION_ADDR (#PCDATA)>
 <!--
 destination mobile number a full international format
 e.g. +447234123456
 -->

<!ELEMENT TEXT (#PCDATA)>
 <!--
 Message text up to 160 characters. If greater than 160 chars
 the value will be truncated to 160 characters and sent out.


 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.)
 -->



<!ELEMENT TRANSACTIONID (#PCDATA)>
 <!--
 max. 50 characters. generated by the third party service.
 A client may set to a constant if preferred, but this will not aid
 reconciliation of delivery statuses or any requested investigation.
 -->

<!ELEMENT TYPEID (#PCDATA)>
WIN - Confidential              Page 29 of 57                                     Printed 07/08/11
Gateway Interface Definition Document
 <!--
 type of message, these are defined in the client application form,
 provides a breakdown of messages in the reports
 -->

<!ELEMENT SERVICEID (#PCDATA)>
 <!--
 the originating service within the third party, these are defined
 in the client application form, provides a breakdown of messages
 in the reports.
 -->

<!ELEMENT COSTID (#PCDATA)>
 <!--
 Provides the charge band
 e.g. 1 = free. These are defined in the client application form

 As well as being used to set the cost to the end user of an MT,
 CostIDs also perform a message routing capability,
 by having a secondary attribute : Routing ID.

 The RoutingID values are a set part of a clients configuration.

 The RoutingID effects the network upon which a message will be dispatched
 and the Originator Address (OA) substitution support :

 The possible routing types are :

 1 ON-NETWORK
  The messages are dispatched via the network of the
   target mobile phone (when known).
  Use this for :
   UK Premium Rate (PR) traffic
   UK On-Network FOC (Free of Charge) traffic.
 4 SNR (Single Network Routing)
  The messages are dispatched via a fixed network independent of the
   target mobile phone network.
  Use this for :
   For dispatch of free messages via the WIN least busy network engine
    (one of Vodafone, mmO2, Orange, T-Mobile)
   FOC/PR non-UK network
    (e.g. Germany, Austria (MATERNA), Ireland (PUCA), Manx Telecom)

 Note there are crossover routing considerations when Originator Address (OA)
 substitution is required. See ELEMENT SOURCE_ADDR description.

 Originator Address (OA) substitution support :
 Dynamic OA support :
  T-Mobile
  WIN least busy network engine

 Static OA support :
  Vodafone
  O2
  Orange
 OA substitution on all other networks is unsupported.

 -->

<!ELEMENT CREATIONDATETIME (DD, MMM, YYYY, HH, MM)>
 <!--
 Time message was created by the third party
 -->

<!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.


WIN - Confidential              Page 30 of 57                                      Printed 07/08/11
Gateway Interface Definition Document
 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)>
 <!--
      Track delivery to :
         0 (default) no delivery receipt
         11                   handset
         12             operator + handset
         13 win processing + operator + handset
         14 win processing + operator
         15             operator
         16 win processing
 DRs are supported across the networks : Vodafone, O2, Orange, T-Mobile
 -->

<!ELEMENT DELIVERYDATETIME (DD, MMM, YYYY, HH, MM)>
 <!--
 The date & time at which the message delivery required
 -->
<!ELEMENT EXPIRYTIME (HH, MM)>
 <!--
 The offset time after which to cease attempting to deliver the
 message to a operator. Also used by the operator as an offset
 from the time the they received the message to the time they
 cease attempting to deliver the message to a phone.
 -->
<!ELEMENT DD (#PCDATA)> <!-- day of month (1-31) -->
<!ELEMENT MMM (#PCDATA)>
 <!-- month description (3 character : JAN, FEB, DEC
 or numeric 1,2, .. 12 ) -->
<!ELEMENT YYYY (#PCDATA)> <!-- year -->
<!ELEMENT HH (#PCDATA)> <!-- hour of day (0-23) -->
<!ELEMENT MM (#PCDATA)> <!-- minute of hour (0-59) -->

<!ELEMENT PRIORITY (#PCDATA)> <!-- integer 1 to 10 (1 highest) -->

<!ELEMENT SOURCE_ADDR (#PCDATA)>
 <!--
 20 characters max. Originator Address (AO) substitution value.
 Note there are crossover routing considerations when Originator Address (OA)
 substitution is required. See ELEMENT COSTID description.
 -->

<!ELEMENT FLASH (#PCDATA)>
 <!--
 TRUE | FALSE place message in idle window
 Not internally implemented as of Version 3.1
 -->

<!ELEMENT BLINK (#PCDATA)>
 <!--
 TRUE | FALSE blink message in inbox
 Not internally implemented as of Version 3.1
 -->

<!ELEMENT REMOVE (#PCDATA)>

WIN - Confidential              Page 31 of 57                                                   Printed 07/08/11
Gateway Interface Definition Document
 <!--
 TRUE | FALSE delete message if possible
 Not internally implemented as of Version 3.1
 -->

<!ELEMENT WINTRANSACTIONID (#PCDATA)>
 <!--
 For a pull service the value supplied here should be the MO TRANSACTIONID
 value provided by WIN when the MO request was presented to the client.
 This usually optional but may be required for services in some countries.
 Although it is usually optional it may prove useful from a client support
 investigation to provide this.
 -->




WIN - Confidential              Page 32 of 57                                Printed 07/08/11
Gateway Interface Definition Document
6.1.2   XML Example
<?xml version="1.0" standalone="no"?>
<!DOCTYPE WIN_DELIVERY_2_SMS SYSTEM "winbound_messages_v1.dtd">

<!-- E.g. -->
<WIN_DELIVERY_2_SMS>

 <!-- E.g. minimal set of elements -->
 <!-- Note Allowable TypeIDs must be agreed with WIN -->
 <SMSMESSAGE>
  <DESTINATION_ADDR>+447940123456</DESTINATION_ADDR>
  <TEXT>Hello World</TEXT>
  <TRANSACTIONID>333444</TRANSACTIONID>
  <TYPEID>2</TYPEID>
  <SERVICEID>1</SERVICEID>
  <COSTID>1</COSTID>
 </SMSMESSAGE>

 <!-- Minimal and popular elements -->
 <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>

<!-- E.g. with all elements -->
<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>

 <!-- Same message to multiple phones -->
 <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>




WIN - Confidential              Page 33 of 57                     Printed 07/08/11
Gateway Interface Definition Document
6.2     TPBound : Messages received from customers
6.2.1    DTD Definition : tpbound_messages_v1.dtd
File 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)> <!-- short code mobile user sent the message to -->
<!ELEMENT SOURCE_ADDR (#PCDATA)> <!-- originating mobile number in international format -->
<!ELEMENT TEXT (#PCDATA)> <!-- Message text up to 160 characters-->
<!ELEMENT WINTRANSACTIONID (#PCDATA)> <!-- Number allocated by WIN -->
<!ELEMENT SERVICEID (#PCDATA)> <!-- ServiceID associated with the keyword -->
<!ELEMENT NETWORKID (#PCDATA)>
<!--
  The mobile phones network that sent the message if known
  (Vodafone=1, 02=2, Orange=3, T Mobile =4,
  Germany=27, Ireland=28, Spain=31,
  Phone network not known = -1) -->

<!ELEMENT ARRIVALDATETIME (DD, MMM, YYYY, HH, MM)> <!-- Time message arrived -->
<!ELEMENT DD (#PCDATA)> <!-- Day of month (1-31) -->
<!ELEMENT MMM (#PCDATA)> <!--3 character month description (JAN, FEB ... DEC) -->
<!ELEMENT YYYY (#PCDATA)> <!-- year -->
<!ELEMENT HH (#PCDATA)> <!-- Hour of day (0-23) -->
<!ELEMENT MM (#PCDATA)> <!--Minute of hour (0-59) -->
<!ELEMENT LOCATION (#PCDATA)> <!-- 100 char max. string location of the mobile -->


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>




WIN - Confidential              Page 34 of 57                                    Printed 07/08/11
Gateway Interface Definition Document
6.3     TPBound : Delivery Receipts
6.3.1     DTD Definition : tpbound_receipts_v3p1.dtd
File name = tpbound_receipts_v3p1.dtd

<!ELEMENT WIN_RECEIPTS (SMSRECEIPT+)>

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

<!ELEMENT SERVICEID (#PCDATA)>
 <!-- INT, service of message -->

<!ELEMENT SOURCE_ADDR (#PCDATA)>
 <!-- originating mobile number in international format -->

<!ELEMENT TRANSACTIONID (#PCDATA)>
 <!-- max. 50 characters. allocated by the third party service when MT was requested. -->

<!ELEMENT NETWORKID (#PCDATA)>
 <!--
  The network that generated the status has been generated where applicable.
  Possible values :
  -1 when not applicable e.g. a WIN internal interim status.
   1 =Vodafone
   2 = O2
   3 = Orange
   4 = T-Mobile
   etc...
   See Interface Definition Document for more comprehensive list.

   NOTE this NetworkID 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

   A complete list of the possible NetworkID values is available within
   CommonIdentifiers.DOC from the standard gateway readme.htm page.
 -->

 <!ELEMENT STATUSID (#PCDATA)>
  <!--
  INT see User Guide for details
  A complete list of possible values is within the Interface Definition Document.
  Some statuses are interim, some are final.
  Which are received are effected by the delivery receipt type choice within the MT request.
  The IDD also provides a guide as to when to retry failed deliveries.
  Some common values are :
   1     WIN Processing
   2     Delivered To Network (final)
   3     Delivered To Network (intermediate)
   4     Operator is Retrying Message
   5     Delivered To Phone
   etc

 -->

 <!ELEMENT STATUSDATETIME (DD, MMM, YYYY, HH, MM, SS)> <!-- Time message arrived -->

 <!ELEMENT DD (#PCDATA)> <!-- Day of month (1-31) -->
 <!ELEMENT MMM (#PCDATA)> <!--3 character month description (JAN, FEB ... DEC) -->
 <!ELEMENT YYYY (#PCDATA)> <!-- year -->
 <!ELEMENT HH (#PCDATA)> <!-- Hour of day (0-23) -->
 <!ELEMENT MM (#PCDATA)> <!--Minute of hour (0-59) -->
 <!ELEMENT SS (#PCDATA)> <!--Seconds of minute (0-59) -->


WIN - Confidential              Page 35 of 57                                               Printed 07/08/11
Gateway Interface Definition Document
 <!-- Message Fragments
 Some messages are encoded at WIN resulting in multiple fragments e.g. Ring tones.
 For these, each of the fragments results in status codes being issued.

 Thus the addition of elements for the delivery receipt reporting of
 fragments for multipart messages :
 -->

<!ELEMENT TOTALFRAGMENTNO (#PCDATA)>
 <!--
 INT, total number of encoded sms msgs
 This is the total number of fragments for the overall message group

 i.e. For ring tone conversion, fragment 0 of 3 would relate to the parent initial
 request, and 1, 2 and 3 to the fragments created as result of the request.
 -->

<!ELEMENT FRAGMENTID (#PCDATA)>
 <!--
 INT, to which encoded sms msgs number this delivery receipt relates
 This is the fragment number within the group i.e. 2 of 3 etc.
 -->




WIN - Confidential              Page 36 of 57                                        Printed 07/08/11
Gateway Interface Definition Document
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><S
S>46</SS></STATUSDATETIME>
 <TOTALFRAGMENTNO>1</TOTALFRAGMENTNO>
 <FRAGMENTID>1</FRAGMENTID>
</SMSRECEIPT>


 <!-- Message Fragments
 Some messages are encoded at WIN resulting in multiple fragments e.g. Ring tones.
 For these, each of the fragments results in status codes being issued.

 Thus the addition of elements for the delivery receipt reporting of
 fragments for multipart messages :

 Below is the delivery receipt for the second part of a three part ring tone.
 -->

<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>




WIN - Confidential              Page 37 of 57                                        Printed 07/08/11
Gateway Interface Definition Document
6.3.3    Gateway StatusID Values
StatusIDs outside the initial 2052 to 2069 are received by V2 gateway customers.
StatusIDs below 1000 are received by V3 gateway customers.

Gateway     Final   Client    Retry                       Error Code Description
StatusID   Status   Retry    Strategy
  2052       Yes      Yes        A      Failed @ WIN
  2053       Yes      No        NA      Delivered To Network (final)
  2054       Yes      No        NA      Delivered To Phone
  2055       Yes      Yes       A       Failed @ Operator
  2068       No       NA        NA      WIN Processing
  2069       No       NA        NA      Operator is Retrying Message
   1         No       NA        NA      WIN Processing
    2        Yes      No        NA      Delivered To Network (final)
    3        No       NA        NA      Delivered To Network (intermediate)
    4        No       NA        NA      Operator is Retrying Message
    5        Yes      No        NA      Delivered To Phone
    6        Yes      Yes        A      Failed @ Operator
    7        Yes      Yes        A      Failed @ WIN
    8        Yes      No        NA      Pulled by      WIN have delivered the MMS payload to
                                        handset        the network's WAP Gateway. (There is still
                                        MMS            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 MMS
   10        Yes      No        NA      Formatting Error SMS too long
   11        Yes      No        NA      Unknown Subscriber
   12*       Yes      Yes      B or     Insufficient   3 : Retry should be 5mins, 2hrs, 24hrs, 48 hrs,
                              special   Credit         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 Barred
   14        Yes      No        NA      Incorrect Billing
   15        Yes      No        NA      Invalid Originator
   16        Yes      Yes       A       Message Expired @ WIN
   17        Yes      No        NA      Invalid Expiry Value
   18        Yes      No        NA      Duplicated Message
   19*       Yes      Yes        C      O2 only.                 In pipe = an earlier request for a
                                        Meaning is one of :      prepay MT is en-route within O2 to be
                                                                 delivered to the phone. Subsequent
                                        Out of Credit.           MT requests are rejected.
                                        Billing System Busy.
                                        Prepay message           It would be beneficial to have a
                                        already In Pipe.         distinctive status code for out of
                                                                 credit.
                                                                 WIN are pressing O2 for this.
   20        Yes      No        NA      Zero Length Data
   21        Yes      No        NA      Binary Too Long
   22        Yes      No        NA      Binary Incorrect Format
   23        Yes      Yes       B       SIM Full
   24        Yes      No        NA      Absent Subscriber
   25        Yes      Yes        A      Error in Delivery To Operator
   26        Yes      Yes        A      Message Expired @ Operator

WIN - Confidential              Page 38 of 57                                Printed 07/08/11
Gateway Interface Definition Document
   27        Yes       No         NA      Not defined - Status Unknown
   99*       Yes       No         NA      Delivery      A final delivery receipt has not been issued by
                                          receipt       the Network Operator for the SMS.
                                          timeout       WIN has timed out waiting for this and has
                                                        therefore issued this final status.
   201       Yes       No         NA      Invalid Login
   202       Yes       No         NA      Invalid XML
   203       Yes       No         NA      XML/Envelope encoding mismatch
   204       Yes       No         NA      Unexpected XML Definition
   206       Yes       No         NA      Maximum File Size Exceeded
   208       Yes       No         NA      Invalid DESTINATION_ADDR
   209       Yes       No         NA      Invalid TYPEID
   210       Yes       No         NA      Invalid ServiceID for used login
   211       Yes       No         NA      Invalid COSTID
   213       Yes       No         NA      Invalid NETWORKID
   214       Yes       No         NA      Invalid PRIORITY
   215       Yes       No         NA      Customer & OFTEL Network lookup failed
   217       Yes       No         NA      DELIVERYDATETIME is too far off (max 7 days)
   252       Yes       No         NA      RING TONE :missing phone code
   253       Yes       No         NA      NOKIA OPERATOR LOGO :missing or invalid Operator Logo
                                          Network
   254       Yes       No         NA      NOKIA BOOKMARK :missing bookmark name
   255       Yes       No         NA      NOKIA BOOKMARK : URL > 50 characters
   256       Yes       No         NA      Reverse Billed Traffic Not Supported for this Type of Traffic
   257       Yes       No         NA      RING TONE :empty RTTL
   258       Yes       No         NA      RING TONE: phone model is not supported
   259       Yes       No         NA      New receipting API not yet supported
   260       Yes       No         NA      Information Only – Message has been fragmented
   261       Yes       No         NA      Barred at WIN – specific phone is barred
   262       Yes       No         NA      Barred at WIN – non-phone specific reason
                                          e.g. short code
   263       Yes       No         NA      Delivered To SMPP system (final)
   264       Yes       No         NA      IMSI Lookup - System Error
   265       Yes       No         NA      IMSI Lookup - Success
   266       Yes       No         NA      IMSI Lookup - Failure
   267       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 :

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


WIN - Confidential              Page 39 of 57                                 Printed 07/08/11
Gateway Interface Definition Document
6.3.4   MT Retry Strategy
A 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                      Time Interval
 Strategy
     A        5 Mins, 15 Mins, 30 Mins, 1 Hour
     B        3 Hours, 5 Hours, 12 Hours, 24 Hours
    C         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.




WIN - Confidential              Page 40 of 57                                 Printed 07/08/11
Gateway Interface Definition Document
6.4     Generic Response
6.4.1     DTD Definition : response_generic_v1.dtd
File name = response_generic_v1.dtd

<!ELEMENT SMSRESPONSE ( REQUESTID )>

<!--

When a HTTP request is made to WIN or to the third party the following will
be the Response XML.
i.e. WIN will return this in response to MT requests (winbound_messages_v1.dtd.)
i.e. The third party will return this in response to MO and delivery statuses
(tpbound_receipts_v3p1.dtd or tpbound_messages_v1.dtd )

There is no corresponding FTP TPBound generic response generated.

-->

<!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.


WIN - Confidential              Page 41 of 57                                      Printed 07/08/11
Gateway Interface Definition Document
 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 Example
Example 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>




WIN - Confidential              Page 42 of 57                                  Printed 07/08/11
Gateway Interface Definition Document
7 Payload types
By 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 Payload
The 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 Header
The 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




WIN - Confidential              Page 43 of 57                            Printed 07/08/11
Gateway Interface Definition Document
7.3     Binary Payload without User Defined Header
The 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 text
      2. 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 type
      3. 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.




WIN - Confidential              Page 44 of 57                              Printed 07/08/11
Gateway Interface Definition Document
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 Operations
e.g. 1|This is a wap test|http://www.bbc.co.uk/mobile|0|Win Operations


@Encoding              Description
Type
1                       Service Indicator
2                       Service Load
3                       Nokia Bookmark
4                       Ericsson
                       Bookmark
5                       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           Description
0                      The @HREF will be requested unaltered.
1                      The @HREF request will have an additional parameter :
                                EAddress=EAddress value
                       This is the mobile phone number of the customer.
                       E.g. +441234123456
                       This 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      Summary
5829        Redirect      Recommended
                          Value
5825        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.


WIN - Confidential              Page 45 of 57                             Printed 07/08/11
Gateway Interface Definition Document
Clients requiring receipts that are currently using earlier versions of the gateway will need to
upgrade to version 3.

Special Note
Please 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.com
Send :
        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 pages
E.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>

WIN - Confidential              Page 46 of 57                               Printed 07/08/11
Gateway Interface Definition Document
Hello World
<br/><br/>
</p>
</card>

</wml>


7.4.2.3    On-line WAP / WML Tutorial
There are quite a few of these. For example :

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

7.4.2.4    WYSIWYG tools
Many 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.




WIN - Confidential              Page 47 of 57                              Printed 07/08/11
Gateway Interface Definition Document
8 Using WIN Converters For Ring tones, Logos, etc.
8.1       Supported Features and handsets
WIN provides converters for the following contents and makes:

Make                 Ring tones          Operator Logos   Picture          Nokia
                     (mono)              (B/W)            Messages         Bookmarks
                                                          (B/W)
Nokia                        X                  X                 X                X
Sagem                        X
Motorola                     X
Sony/Ericsson                X
Siemens                      X
Samsung                      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 tones
Content 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,16
d,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 Logos
In 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.

WIN - Confidential              Page 48 of 57                          Printed 07/08/11
Gateway Interface Definition Document
           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|00480E010FE000800040000000781800FFFFC01C0E0040000000C00022118000010000
C00201409010230001E0000100E01F044423F02144003020080007F880A0040C600E0784
687801000840382FDDCEFC80C0080260CFDCAEFC31821020638FFDEFFC4C01F000410
FDDEEFC84680C0C400FDFFEFC842006286107800078182282

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.
00481C01DBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0
f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfD
BC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC34
8792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792f
a1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f
7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bfDB
C348792fa1b0f7bfDBC348792fa1b0f7bfDBC348792fa1b0f7bf

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

8.5        Nokia Bookmark
The 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.


WIN - Confidential              Page 49 of 57                            Printed 07/08/11
Gateway Interface Definition Document
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    Benefits
The 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.




WIN - Confidential              Page 50 of 57                             Printed 07/08/11
Gateway Interface Definition Document
8.6.3   How to make use of this service
If 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>
  <!--
  Do not include any additional elements to those shown below.
  E.g. the phone user will be unaware of an IMSI request and so
  a SOURCE_ADDR is not relevant.
  -->
  <DESTINATION_ADDR>+447740630111</DESTINATION_ADDR>
  <DESTINATION_ADDR>+447740630135</DESTINATION_ADDR>
  <DESTINATION_ADDR>+447740630159</DESTINATION_ADDR>
  <TEXT></TEXT>                             <!-- Note leave this value blank -->
  <TRANSACTIONID>CEL9</TRANSACTIONID> <!-- Set value as required -->
  <TYPEID>2</TYPEID>                   <!-- Set value as required -->
  <SERVICEID>1</SERVICEID>                  <!-- Set value as required -->
  <COSTID>10</COSTID>                   <!-- agreed IMSI lookup value,
                             this value will differ from client to client -->
  <DELIVERYRECEIPT>13</DELIVERYRECEIPT><!-- must request type 13 -->
 </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.




WIN - Confidential              Page 51 of 57                                  Printed 07/08/11
Gateway Interface Definition Document
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 &#x20AC; or decimal
&#8364;.

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>




WIN - Confidential              Page 52 of 57                                       Printed 07/08/11
Gateway Interface Definition Document
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 ]]> &#x00C4; &#x20AC; &#xA3;<![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 &gt; me </message>

There are 5 predefined entity references in XML:
              &lt;     <     less than
              &gt;     >     greater than
              &amp; &        ampersand
              &apos; '       Apostrophe
              &quot; "       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 &gt; 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.



WIN - Confidential              Page 53 of 57                                     Printed 07/08/11
Gateway Interface Definition Document
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 :
        http://www.wincast.com/gatewaydemo/smsHTTP/readme.htm




WIN - Confidential              Page 54 of 57                           Printed 07/08/11
Gateway Interface Definition Document
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 myself
If 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.

WIN - Confidential              Page 55 of 57                                Printed 07/08/11
Gateway Interface Definition Document
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 :

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


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 me
WIN provides converters for a limited sets of handsets. Please see the section about „Using
WIN Converters For Ringtones, Logos, etc.‟ in this document.




WIN - Confidential              Page 56 of 57                                Printed 07/08/11
Gateway Interface Definition 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.




WIN - Confidential              Page 57 of 57                            Printed 07/08/11
Gateway Interface Definition Document

								
To top