CPA SMS Bulk API: Implementation guide

(c) 2006-2024 Telia Norge AS. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright holder. The contents of this document are subject to revision without notice. Telia shall have no liability for any error or damages of any kind resulting from the use of this document.

Revisions

Version	Comment
1.09	Updated SMS DR DeliveryTime format to correct format (yyyyMMdd:HHmmss)
1.10	Changed WSDL URL in SMS MO/DR Java code example to correct URL
1.11	Updated WS URL’s. Updated price information in chapter. Appendix A Prices deleted
1.12	Webservice endpoints are changed. Cost information changed. Price annex removed. General clean up
1.13	Maximum number of recipients in one Submit request reduced to 64
1.14	Changed description of binary messages
1.15	Changed Originating Address definitions
1.16	Changed Originating Address validation rules and description
1.16.1	New logo inserted
1.16.2	Changed description of cref
1.16.3	Added success code in Appendix B
1.16.4	New logos and brand name. New error code 9903
1.17	Removed old logo in diagram under section 1.2. New URLs for new consolidated platform. Removed note about delivery time restriction under delivery time chapter.
1.18	Removed obsolete tutorials and code examples. Added example of sending an emoji message. Added example of receiving an emoji message. Added a chapter regarding charging of messages.
1.19	Fixed 7-bit alphabet appendix in HTML version. Updated WSDL addresses. Added support for slash character in OA (see Submit request)
1.20	Added status codes for Sender ID Protection.

Introduction

The CPA SMS Bulk API enables content providers to deliver free SMS messages to subscribers in all networks where Telia has an interconnect agreement. Content providers can only receive SMS messages from subscribers in Telia’s network.

This implementation guide is valid for the CPA SMS Bulk platform launched in 2019, supporting both the Telia and the OneCall/MyCall networks.

Audience

This document is intended for developers implementing SMS services. It contains a description of technical details necessary to understand in order to successfully integrate an IT application with the SMS infrastructure provided by the mobile operator.

This document assumes thoroughly knowledge about the GSM/UMTS Short Message Service (SMS) architecture.

In addition to this document, the user should be familiar with the CPA agreement.

Functional overview

CPA SMS supports:

Sending mobile terminated (MT) short messages to end-users
Receiving mobile originated (MO) short messages sent by end-users
Receive delivery report (DR) messages for all submitted MT messages

The figure above provides an overview of how SMS messages are sent between mobile subscriber and a content provider

The mobile subscriber sends a SMS message to a content provider by using the access number assigned to the content provider as a recipient.
Any SMS message sent by mobile subscribers is received by Telia’s Short Message Services Center (SMSC). The SMSC routes the incoming SMS message to the CPA SMS platform based on the access number specified. CPA SMS platform is then responsible for routing the message to the content provider’s content service.
Content Provider sends messages to a mobile subscriber by specifying the mobile subscriber identity (MSISDN) as a recipient of the message and submitting the message to CPA SMS platform.
CPA SMS validates the request from the content providers before forwarding the message to the SMSC, which delivers the message to the mobile subscriber.

For more information about the CPA services, see https://telia.no/cpa.

Reference architecture

CPA SMS platform offers its services to the content provider using a set of SOAP-compliant web services.

In order to send SMS MT messages, the content provider must provide a client-side implementation of the SMS MT web service. CPA SMS platform provides no client library; instead available standard SOAP-compliant toolkits can be used to generate clients. The CPA SMS platform provides the server-side implementation of the SMS web service responsible for forwarding the received MT messages to the SMSC.

In order to receive SMS MO and DR messages, the content provider must provide a server-side implementation of the SMS MO/DR web service based on the WSDL provided by CPA SMS platform.

CPA SMS platform will put any received MT message in a queue before delivering the message to the SMSC. The message is forwarded to the SMSC if the message complies with the policy implemented by CPA SMS Business Logic. For each SMS MT message sent by the content provider, a corresponding SMS Delivery Report (DR) message will be returned to the content provider. The SMS Delivery Report contains information about the delivery status of a single message. The content provider must keep track of received SMS DR messages in order to determine if the message have been delivered to the mobile subscriber or not.

Message flows

CPA SMS web service consists of a pair of request/response messages sent to/from content provider and CPA platform. The following sections describe the message exchange involved in a sending and receiving SMS messages.

SMS mobile terminating (MT) message flow

The first part of the sequence below shows the content provider initiating a Submit message exchange in order to send a SMS MT message to the CPA platform. If the Submit request is valid, the CPA platform puts the received message in a queue before returning the Submit Response message. The CPA platform then forwards any message received to the SMSC, which finally delivers the message to the mobile subscriber.

Once the mobile subscriber receives the SMS MT message, a delivery report is returned to the SMSC. The delivery report is then routed to the CPA platform, which attempts to transmit the delivery report to the content provider using a Delivery Report message exchange.

@startuml
ContentProvider --> CPA: Submit Request
CPA --> ContentProvider: Submit Response

CPA --> SMSC: Submit message
SMSC --> Subscriber: Send SMS
SMSC --> CPA: Deliver delivery report
CPA --> ContentProvider: Delivery report request
ContentProvider --> CPA: Delivery report response
@enduml

Note	Note: The Submit Response is returned before the message is delivered to the SMSC. Also, the message may never be delivered to the SMSC if the message violates the policy implemented by the CPA platform.

SMS mobile originating (MO) message flow

The sequence illustrates how a SMS message sent from a mobile subscriber is routed from the SMSC to the content provider via the CPA platform.

An end-user sends a SMS message to a specified access number. The message is received by the SMSC which forwards the message to the CPA platform. The CPA platform then attempts to issue a Deliver request to the configured Content Provider. The Content Provider solution must then return a correct Deliver response message if the message has been successfully received.

If the CPA platform is unable to deliver the SMS MO message to the Content Provider, the CPA platform will attempt to deliver the message again after a pre-configured time-interval.

@startuml
Subscriber --> SMSC: Send MO message
SMSC --> CPA: Deliver message
CPA --> ContentProvider: Deliver request
ContentProvider --> CPA: Deliver response
@enduml

Charging of messages

SMS messages are charged the CPA SMS Bulk Customer according to the fees set out in the CPA Agreement. SMS MT Messages (sent to the mobile terminal) are charged per segment for all valid Submit requests (ref. chapter 1.5.1 above).

Messages to mobile subscribers connected to Telia Norway mobile networks (identified by the terminating network code 815 according to the NRDB database, http://nrdb.no) will be charged as on-net.

Messages to mobile subscribers connected to other networks than the Telia Norway mobile networks (identified by the terminating network code 815 according to the NRDB database, http://nrdb.no) will be charged as off-net/domestic.

Messages to mobile subscribers connected to networks outside of Norway (identified by the recipient MSISDN prefix not being +47) will be charged as foreign.

Getting started

CPA Agreement

Access to the CPA SMS Bulk API requires a CPA agreement with Telia. For more information, see Telia’s website (https://telia.no/cpa).

System requirements

The content provider needs the following:

SOAP 1.2-compliant Software Development Kit (SDK)
Web server with fixed IP addresses

Telia SMS Bulk API provides a SOAP-based web service interface which is compliant with WS-I Basic Profile 1.0 recommendations. As such, the web service interface should be compliant with most commonly used SOAP toolkits.

The web service API has been verified against the following platforms:

Microsoft .Net Framework version 1.1, 2.0, 3.0, 3.5
Apache Axis version 1.4
Java JAX-WS 2.0, 2.1
PHP 5.0

Web service URLs

The SMS (SMS MT) web service definition (WSDL) is available from the following URL: https://api.messaging.telia.no/smsbulk/ws/v2/wsdl/smsbulk.wsdl

The SMS callback (SMS MO/DR) web service definition (WSDL) is available from the following URL: https://api.messaging.telia.no/smsbulk/ws/v2/wsdl/smscallback.wsdl

Web service endpoint to send SMS messages: https://api.messaging.telia.no/smsbulk/ws/v2

Message formats

Each operation supported by CPA SMS consists of a pair of request/response messages exchanged between the content provider and CPA platform. The messages are transmitted as SOAP envelopes according to the SOAP 1.2 specification. Each message described in the following sections is encoded as part of the SOAP envelope body.

<?xml version="1.0" encoding="UTF-8"?>
<soap:envelopexmlns="http://differitas.no/2006/09/messaging/sms">
    <soap:header>
    </soap:header>
    <soap:body>
        <SubmitReq |SubmitRsp | DeliverReq | DeliverRsp | DeliveryReportReq | DeliveryReportRsp />
    </soap:body>
</soap:envelope>

Addressing

The CPA SMS Bulk platform is responsible for routing SMS messages between content providers and mobile subscribers. Each content provider is uniquely identified by an access number (e.g. 26123), while mobile subscribers are identified using an MSISDN number (e.g. 4712345678).

Each message routed through the CPA system contains the following addressing information:

Destination address (DA) – identifies the recipient of a SMS message
Originating address (OA) – identifies the sender of a SMS message

For SMS messages sent FROM a mobile subscriber TO a content provider (SMS MO), the originating address will be set to the mobile subscriber identity (MSISDN) while the destination address will be set to the content provider access number.

For SMS messages sent FROM a content provider TO a mobile subscriber (SMS MT), the destination address will be set to the mobile subscriber identity (MSISDN). The originating address can be set depending on the authorization level given to the content provider. There are two authorization levels:

Fixed originating address: The access number + an optional sub number, or an alphanumeric string. When using sub numbers, the OA shall consist of 13 - 15 digits.
Free originating address. Any account number (including sub number), alphanumeric string and any phone number (fixed and mobile) are allowed.

Submit messages

SMS MT messages are sent using as SubmitReq/SubmitRsp message exchange.

Submit request

The following XML fragment illustrates a minimum Submit message sent from access number 12345 to mobile subscriber 4712345678.

SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
    <SubmitMessagecref="45678">
        <Account>12345</Account>
        <DA>4712345678</DA>
        <Content>
            <Text>This is a text message.</Text>
        </Content>
    </SubmitMessage>
</SubmitReq>

Information element	Comment
cref	Client reference – must be unique for each SubmitMessage. The client reference is used to track submitted messages and correlate any delivery report messages. The cref can be maximum 64 characters. The cref may be reused after one year.
Account	The originating account (or accessnumber) sending the message. Must be a 4- or 5-digit number.
DA	The recipient of the message. The following MSISDN formats are supported: MSISDN number including country prefix (e.g. 4712345678) MSISDN number including country prefix with leading ‘+’ (e.g. +4712345678) MSISDN number including country prefix with leading 00 (e.g. 004712345678)
OA	Optional. Originating address as displayed on the mobile terminal. By default, the access number is displayed as originating address. The following formats are supported (): 4- or 5-digit access number (default) 8- or 12-digit phone number National numbers may be prefixed by +47 International numbers must be prefixed by + or 00 Alphanumeric address Maximum length is 11 characters where characters can be one of the following: Alphanumeric characters in GSM 7-bit character set (see GSM 7-bit default alphabet table) Space, Percentage (%), Slash (/), Ampersand (&), Minus (-), Plus (+), Period (.) and Comma (,) () Special permission must be granted, see previous sections
Content	Message content, either text or binary

Information element

Comment

cref

Client reference – must be unique for each SubmitMessage. The client reference is used to track submitted messages and correlate any delivery report messages. The cref can be maximum 64 characters. The cref may be reused after one year.

Account

The originating account (or accessnumber) sending the message. Must be a 4- or 5-digit number.

The recipient of the message. The following MSISDN formats are supported:

MSISDN number including country prefix (e.g. 4712345678)
MSISDN number including country prefix with leading ‘+’ (e.g. +4712345678)
MSISDN number including country prefix with leading 00 (e.g. 004712345678)

Optional. Originating address as displayed on the mobile terminal. By default, the access number is displayed as originating address. The following formats are supported (*):

4- or 5-digit access number (default)
8- or 12-digit phone number
- National numbers may be prefixed by +47
- International numbers must be prefixed by + or 00
Alphanumeric address
- Maximum length is 11 characters where characters can be one of the following:
  - Alphanumeric characters in GSM 7-bit character set (see GSM 7-bit default alphabet table)
  - Space, Percentage (%), Slash (/), Ampersand (&), Minus (-), Plus (+), Period (.) and Comma (,)

(*) Special permission must be granted, see previous sections

Content

Message content, either text or binary

Note	Client reference must be unique for each SubmitMessage. CPA SMS uses this value to ensure that SMS message is delivered only once. If a non-unique client reference value is detected, a delivery report is returned and the message is discarded.

Text messages

By default, SMS messages sent to/from a mobile terminal are encoded using GSM-7 bit character set, which only supports a limited set of characters (see GSM 7-bit default alphabet table). The XML message format used by the CPA SMS protocol uses UTF-8 character encoding. Hence, the CPA platform will convert SMS message text between the different character set.

Note	The CPA platform will reject any SMS text message that contains characters not defined by the GSM 7-bit character set. For information about how to use other character sets, see Unicode text messages

Long text messages

When a single SMS MT text message exceeds 160 characters (using GSM-7 bit character set) the message will be split into multiple parts by the CPA SMS platform. Each message part will be sent as concatenated SMS message to the mobile subscriber. For mobile terminals supporting concatenated SMS messages, the message parts will be displayed as a single SMS message. If concatenated SMS messages are not supported, each message part is displayed as single SMS message.

The content provider will receive a single delivery report message for long text messages. If one of the message parts is not delivered successfully, the delivery of the complete message is considered failed. In order to be a successful delivery, all message parts must be delivered successfully.

Example:

<SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
    <SubmitMessagecref="45678">
        <Account>12345</Account>
        <DA>4712345678</DA>
        <Content>
            <Text>This is a long message that exceeds 160 characters. Normally, this is sent as two separate messages, but if the type is context, the message parts will be reassembled on the handset and appear as a single message.</Text>
        </Content>
    </SubmitMessage>
</SubmitReq>

Note	Maximum length of text messages using default character set is 960 letters (i.e. 6 messages à 160 letters)

Multipart text messages

When CPA SMS platform splits long text messages into concatenated SMS message, the text might be divided in the middle of a word. In some scenarios, the content provider wants to provide a more intelligent splitting of text-messages. This can be done by sending the text as a multipart text message as illustrated below.

Example:

<SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
    <SubmitMessage cref="1178282868465">
        <Account>12345</Account>
        <DA>4712345678</DA>
        <Content>
            <Text header="06080400040201">This is first part.</Text>
            <Text header="06080400040202">This is second part.</Text>
        </Content>
    </SubmitMessage>
</SubmitReq>

A multipart text message is transmitted using several <Text> elements; each element assigned a header value indicating the sequence of the multipart message. For information about valid header values, see reference Technical realization of the Short Message Service (SMS).

Note	When sending multipart text message, each part should not exceed 160 characters.

Unicode text messages

CPA SMS supports sending text messages with the following character encoding alphabets:

GSM 7-bit character set
UTF-16

By default, GSM 7-bit character set is used. For information about characters available in GSM 7-bit character set, see GSM 7-bit default alphabet table.

While GSM 7-bit uses 7-bit to represent a character, UTF-16 use 16-bits. Some Unicode characters like emojis will require a UTF-16 surrogate pair and will use 32 bits. A single UTF-16 encoded SMS message has a maximum length of 140 bytes – or 70 characters if not using UTF-16 surrogates. When a single SMS MT message exceeds 140 bytes using UTF-16 encoding, the message will be split into multiple parts by the Telia CPA SMS platform. Each message part will be sent as concatenated SMS message to the mobile subscriber (as described in section: Long text messages).

In order to send UCS2 encoded messages, the data coding schema (DCS) must be set to 8.

Example:

<SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
    <SubmitMessagecref="45678">
        <Account>12345</Account>
        <DA>4712345678</DA>
        <Content>
            <Text>АБВГДЕЖЗИКЛМНОПСТФХЦЧШЩЪЫЬЮѲѴ</Text>
            <DCS>8</DCS>
        </Content>
    </SubmitMessage>
</SubmitReq>

Example of sending message with emoji:

<SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
    <SubmitMessagecref="45678">
        <Account>12345</Account>
        <DA>4712345678</DA>
        <Content>
            <Text>Message with emoji: &#128515;</Text>
            <DCS>8</DCS>
        </Content>
    </SubmitMessage>
</SubmitReq>

Note	Not all mobile terminals support Unicode encoded messages or all unicode characters.

Backward compatibility

In early releases, Unicode messages had to be hex encoded before transmitted. This format is supported for backward compatibility.

Note	Each Unicode character should be hex encoded using Big-endian format (UTF-16BE). Little endian format is not supported.

Example:

    <SubmitMessage cref="45678">
        <Account>12345</Account>
        <DA>4712345678</DA>
        <Content>
            <Text>041004110412041304140415041604170418041A041B041C041D041E041F04210422042404250426042704280429042A042B042C042E04720474
            </Text>
            <DCS>8</ DCS>
        </Content>
    </SubmitMessage>
</SubmitReq>

The text above is the Russian text: “АБВГДЕЖЗИКЛМНОПСТФХЦЧШЩЪЫЬЮѲѴ”. The cyrillic letter ’A’ in the example is encoded using the hex-value ’0410’.

Warning

Implementations using hex formatted text messages should switch to use new format without hex encoding. Support may be removed in future releases without further notice.

Binary messages

CPA platform supports sending binary content to a mobile subscriber using the SMS protocol. A binary SMS message is divided into four parts:

User Data Header (UDH)
User Data (UD)
Data Coding Schema (DCS)
Protocol Identifier (PID)

SMS CPA platform uses the following XML fragment to encode the binary content:

<SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
    <SubmitMessage cref="45678">
        …
        <Content>
            <Binary header="[User Data Header (UDH)]">[User Data (UD)]></Binary>
            <DCS>4</DCS>
            <PID></PID>
        </Content>
    </SubmitMessage>
</SubmitReq>

Binary messages are sent as hex-encoded strings. Maximum length of a single binary message part is 280 hex-encoded characters (i.e. 140 bytes).

Binary content encoding is defined by different standards, i.e. Enhanced Messaging (supported by Sony Ericsson, Siemens etc.) and Nokia Smart Messaging. For examples and information about how to encode binary content see References.

Data coding schema (DCS)

Binary messages are sent as hex-encoded strings. Maximum length of a single binary message part is 280 hex-encoded characters (i.e. 140 bytes).

For information about other DCS values, see GSM specification.

Protocol identifier (PID)

Protocol identifier is an optional parameter supported by CPA SMS. For information about PID values, see GSM specification.

Example: EMS bitmap

The following example shows how to send an EMS bitmap:

<SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
    <SubmitMessage cref="1178267923477">
        <Account>12345</Account>
        <DA>4712345678</DA>
        <Content>            <Binary>8310810063001400F7801CA0FF8009F0FF8A01F07F0E40E03E0400401C00000A08FFFE0E07FFFFC40F8003E05C0000701810103018583430382C583830FC7E18303C781A3A3C78B8351831583A0000B83506C158BA4FE4B8183FF830181970351C0FE0774F8003E207FFFFC000FFFE0050000014F800503EF940713E71C4201C20800008</Binary>
            <DCS>4</DCS>
        </Content>
    </SubmitMessage>
</SubmitReq>

Example: Nokia Smart Messaging - Ringing Tone

The following example illustrates how to send a ringing tone using Nokia Smart Messaging encoding.

<SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
    <SubmitMessage cref="1178279377809">
        <Account>12345</Account>
        <DA>4712345678</DA>
        <Content>
            <Binary header="0b05041581c0020003000101">024A3A51D195CDD004001B20550590610560558550548540820849900000</Binary>
            <DCS>4</DCS>
        </Content>
    </SubmitMessage>
</SubmitReq>

Example: EMS bitmap - multiple message parts

The following example illustrates how to send an EMS bitmap which extends more than one SMS message part (i.e. total bytes > 140):

<SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
  <SubmitMessage cref="1178278882943">
    <Account>12345</Account>
    <DA>4712345678</DA>
    <Content>
      <Binary header="0b0504158ac0020003000901">
        300000045465737402010000481C0166666666666666666699999999999999</Binary>
      <Binary header="0b0504158ac0020003000902">
        9999800000000000000001400000006000E000024000000E90031000028000</Binary>
      <Binary header="0b0504158ac0020003000903">
        0031080CF3B801800000400411044401400000FFFE2F8B1202400000000053</Binary>
      <Binary header="0b0504158ac0020003000904">
        8CAA0280000000006289C40180000000004141400140000000000142800240</Binary>
      <Binary header="0b0504158ac0020003000905">
        00200000014280028001F0000000A28001800FFE000000A500015FFFFFFFFF</Binary>
      <Binary header="0b0504158ac0020003000906">
        FEA57FFA400AAA0000005500028201500440015D08A1881024800040FF0201</Binary>
      <Binary header="0b0504158ac0020003000907">
        404100010003ABE00244000008200D55588280101440001AAAAC0180000000</Binary>
      <Binary header="0b0504158ac0020003000908">
        003555560140010000806AAAAB024000000000555555028000000000000000</Binary>
      <Binary header="0b0504158ac0020003000909">
        99996666666666666666660199999999999999</Binary>
      <DCS>4</DCS>
    </Content>
  </SubmitMessage>
</SubmitReq>

Example: WAP push message

The following example illustrates how to send a WAP Push message:

<SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
  <SubmitMessage cref="1178279936476">
    <Account>12345</Account>
    <DA>4712345678</DA>
    <Content>
      <Binary header="0605040b8423f0">
        01060baeaf82b15465737400b48101056a0045c60c037761702e76672e6e6f0008010357617020707573682074657374206d657373616765000101
      </Binary>
      <DCS>4</DCS>
    </Content>
  </SubmitMessage>
</SubmitReq>

Multiple recipients

A SMS message can be sent to multiple recipients in a single request. This feature would provide increased performance when sending identical SMS messages to a huge number of recipients.

When sending a single SMS message with multiple recipients, a single message identifier is returned as part of the SubmitResponse. However, a single SMS DR message is returned for each destination. I.e. a SubmitMessage with 8 destinations will generate 8 SMS DR messages each with the identical message identifier. The content provider must be able to map each SMS DR based on message identifier/cref and destination MSISDN.

Multiple recipients are added to the Destinations element of a SubmitMessage as illustrated below.

Example:

<SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
    <SubmitMessagecref="client-provided-reference">
        <Account>12345</Account>
        <Destinations>
            <DA>4712345678</DA>
            <DA>4712345679</DA>
            <DA>4712345680</DA>
            <DA>4712345681</DA>
        </Destinations>
        <Content>
            <Text>This is a text message.</Text>
        </Content>
    </SubmitMessage>
</SubmitReq>

Note	Maximum number of destination addresses in a single request is 64. If more recipients are added, the server will return a SOAP validation fault.

Cost

The service does not support charging the end user. Therefore, the Cost and Currency elements are not in use.

Information element	Comment
Cost	Optional. Not in use for SMS Bulk service.
currency	Optional. Not in use for SMS Bulk service.

Information element

Comment

Cost

Optional. Not in use for SMS Bulk service.

currency

Optional. Not in use for SMS Bulk service.

Service type and category

Service type and category provides support for additional settlement and billing related information to each SMS message. Service type and category are optional. Refer to https://cpa.telia.no for details.

Example:

<SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
    <SubmitMessagecref="45678">
        <Account>12345</Account>
        <DA>4712345678</DA>
        <Content>
            <Text>This is a text message.</Text>
        </Content>
        <Service type=”001” category=”01” />
    </SubmitMessage>
</SubmitReq>

Information element	Comment	Validation rules
category	Specifies the service category	Mandatory 2-digit value.
type	Specifies the service type.	Mandatory 3-digit value.

Information element

Comment

Validation rules

Message delivery and expiry

SMS is a best-effort service. Any message received from the content provider will be attempted delivered to the mobile subscriber as soon as possible. If the SMS CPA platform is unable to deliver the message immediately, the SMS CPA platform will periodically attempt to deliver the SMS message until a maximum time period has elapsed. At this point, the message will be marked as expired.

The expiry time specifies the latest time when a message should be attempted delivered. If the message is not delivered within the specified expiry time interval, the message delivery will expire. The content provider will receive a delivery report with “expired” status.

The delivery time specifies the earliest time when a message should be attempted delivered. By setting the delivery time, the content provider can control the first time MT messages are attempted delivered to a mobile subscriber.

Both the delivery and expiry time can be specified as absolute or relative timestamps. Absolute timestamps are specified using local time zone.

Absolute date format: yyyy-MM-ddTHH:mm:ss where

yyyy indicates the year
MM indicates the month
dd indicates the day
T indicates the start of the required time section
HH indicates the hour (using 24-hour clock)
mm indicates the minute
ss indicates the second

Relative date format: PnYnMnDTnHnMnS where

P indicates the period (required)
nY indicates the number of years
nM indicates the number of months
nD indicates the number of days
T indicates the start of a time section (required)
nH indicates the number of hours
nM indicates the number of minutes
nS indicates the number of seconds

Example:

<SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
    <SubmitMessagecref="123456">
        <Account>12345</Account>
        <DA>4712345678</DA>
        <Content>
            <Text>This is a text message.</Text>
        </Content>
        <DeliveryDate>2007-04-25T19:00:00</DeliveryDate>
        <ExpiryDate>2007-04-27T23:59:00</ExpiryDate>
    </SubmitMessage>
</SubmitReq>

Information element	Comment
DeliveryDate	The earliest desired time of delivery to the recipient
ExpiryDate	The desired time of expiry to the recipient

Information element

Comment

DeliveryDate

The earliest desired time of delivery to the recipient

ExpiryDate

The desired time of expiry to the recipient

Age limit

All content providers are responsible for ensuring that content sold is not inappropriate based on the end-users age. This includes any content which is considered violent, pornographic or similar. Content provider is responsible for classifying their content according to a minimum age. The CPA platform will block any content for end-user’s not compliant with the age limit.

The age limit is specified by assigning the minimum age to each SMS MT message. In the following example, the content is only delivered to end-users which are at least 18 years old.

Note	TheThe age limit check uses the end-user’s birth date (if available), and not the birth year.

Example:

<SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
    <SubmitMessagecref="123456">
        <Account>12345</Account>
        <DA>4712345678</DA>
        <Content>
            <Text>This is a text message.</Text>
        </Content>
        <Rating AgeLimit=”18”/>
    </SubmitMessage>
</SubmitReq>

The content provider will receive a "rejected" SMS DR message if the message is blocked due to age limit violation. See Delivery report status codes for details about the SMS DR message status codes.

Sub-number

CPA SMS supports adding a sub-number to the originating address on SMS MT messages. Instead of using the access number, a 9-digit sub-number is added to the access number and used as originating address.

A SMS MT message sent from account 12345 with a 9-digit sub-number will be received by the recipients as if the message was sent from 12345123456789. When the end-user replies on this message, the destination address of the SMS MO message will be set to 12345123456789.

The originating address should be 14-digits when using sub-number. When using a 5-digit access number, the sub-number should be 9-digits.

Example:

<SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
    <SubmitMessagecref="123456">
        <Account>12345</Account>
        <OA>12341234567890</OA>
        <DA>4712345678</DA>
        <Content>
            <Text>This is a text message with sub-number.</Text>
        </Content>
</SubmitMessage>

Submit response

The Submit response message depends on whether the received message is accepted by the CPA platform or not.

The following XML fragment isbe returned as a response to a Submit request message for successful received message.

<?xml version="1.0" encoding="UTF-8"?>
<SubmitRsp xmlns="http://differitas.no/2006/09/messaging/sms">
  <ReportMessage cref="123456" id="98765">
    <Status code="200">Successful</Status>
  </ReportMessage>
</SubmitRsp>

Information element	Comment
cref	Client reference associated with the submit message.
id	If status indicates success this contains the CPA SMS generated identification of the submitted message. This ID may be used in subsequent requests and delivery reports relating to this message.
status	Status of the completion of the submission. No indication of delivery status is implied. For list of status codes, see Delivery report status codes.

Information element

Comment

cref

Client reference associated with the submit message.

If status indicates success this contains the CPA SMS generated identification of the submitted message. This ID may be used in subsequent requests and delivery reports relating to this message.

status

Status of the completion of the submission. No indication of delivery status is implied. For list of status codes, see Delivery report status codes.

When a Submit request fails, the client receives different response message based on the type of errors. Also, the response behavior depends on the SOAP toolkit used.

Network problems will be returned to clients as standard HTTP error codes.
Security errors, i.e. failed authentication, is returned as standard HTTP error code, i.e. 401 Unauthorized.

When submit request is received by the CPA platform, it can either be accepted (described above) or it can cause two SOAP faults to be returned:

Validation errors of the incoming Submit message will result in a custom SOAP fault, called ValidationFault.
Internal server errors will result in a custom SOAP fault, called ServerFault.

Deliver messages

SMS MO messages are sent using as DeliverReq/DeliverRsp message exchange.

Deliver request

The following XML fragment illustrates a MO message sent from a mobile subscriber (47123456789) to a content provider (12345):

<DeliverReq xmlns:tns="http://differitas.no/2006/09/messaging/sms">
  <DeliverMessage id="346786435">
    <Account>12345</Account>
    <OA>4712345678</OA>
    <DA>12345</DA>
    <Content>
      <Text header="123124">sdfasfdf</Text>
    </Content>
    <DeliveryTime>20070427:235900</DeliveryTime>
  </DeliverMessage>
</DeliverReq>

Information element Comment

Information element	Comment
Id	SMS CPA generated message identifier
Account	The account receiving the message.
OA	The originating sender address (i.e. mobile subscriber)
DA	The recipient of the message (i.e. the content provider identified by access-code)
Content	Message content, either text or binary
DeliveryTime	Time when message was sent by the mobile subscriber. Format: `yyyyMMdd:HHmmss` yyyy indicates the year MM indicates the month dd indicates the date HH indicates the hour using 24-hour clock mm indicates the minutes ss indicates the seconds Example: 20070427:235900

SMS CPA generated message identifier

Account

The account receiving the message.

The originating sender address (i.e. mobile subscriber)

The recipient of the message (i.e. the content provider identified by access-code)

Content

Message content, either text or binary

DeliveryTime

Time when message was sent by the mobile subscriber. Format: yyyyMMdd:HHmmss

yyyy indicates the year
MM indicates the month
dd indicates the date
HH indicates the hour using 24-hour clock
mm indicates the minutes
ss indicates the seconds

Example: 20070427:235900

Unicode encoded SMS MO messages

SMS MO messages encoded as Unicode will be forwarded using the same format as described for SMS MT messages. The <Text> element contains the message text, while the data coding schema of 8 indicates that the message was sent as a UTF-16 encoded text message.

Example:

<DeliverReq xmlns:tns="http://differitas.no/2006/09/messaging/sms">
  <DeliverMessage id="346786435">
    <Account>12345</Account>
    <OA>4712345678</OA>
    <DA>12345</DA>
    <Content>
      <Text>АБВГДЕЖЗИКЛМНОПСТФХЦЧШЩЪЫЬЮѲѴ</Text>
      <DCS>8</DCS>
    </Content>
    <DeliveryTime>20070427:235900</DeliveryTime>
  </DeliverMessage>
</DeliverReq>

Example of emoji message:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<DeliverReq xmlns="http://differitas.no/2006/09/messaging/sms">
    <DeliverMessage id="8f5f5fc4-6d68-41c6-9a5e-8d1978d361b6">
        <Account format="shortcode">8419</Account>
        <OA format="number">4793859166</OA>
        <DA format="shortcode">8419</DA>
        <Content>
            <Text>Message with emoji: 👍</Text>
            <DCS>8</DCS>
        </Content>
        <DeliveryTime>20190918:145607</DeliveryTime>
    </DeliverMessage>
</DeliverReq>

Multipart MO text messages

A multipart MO text message is transmitted using multiple messages; each message containing a <Text> element assigned a header value indicating the sequence of the multipart message. For information about valid header values, see reference Technical realization of the Short Message Service (SMS)

Multipart SMS MO text messages must be concatenated by the content providers.

Example:

The following text sent from a phone to shortcode 1234 is delivered to the content provider as two DeliverReq messages.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras nec libero et orci faucibus cursus. Donec dolor sem, euismod vel viverra vitae, pulvinar nec turpis. Curabitur ac ipsum et tellus rutrum bibendum non quis ligula. Maecenas sagittis ante non orci malesuada tincidunt. In vel eros nisi.

The first message:

<DeliverReq xmlns:ns2="http://schemas.microsoft.com/2003/10/Serialization/" xmlns="http://differitas.no/2006/09/messaging/sms">
  <DeliverMessage id="72a22b0b-543f-4c2d-88f5-4e1d3e0f9288">
    <Account format="shortcode">12345</Account>
    <OA format="number">4712345678</OA>
    <DA format="shortcode">12345</DA>
    <Content>
      <Text header="050003010201">Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras nec libero et orci faucibus cursus. Donec dolor sem, euismod vel viverra vitae, pulvinar ne</Text>
      <DCS>0</DCS>
    </Content>
  </DeliverMessage>
</DeliverReq>

The second message:

<DeliverReq xmlns:ns2="http://schemas.microsoft.com/2003/10/Serialization/" xmlns="http://differitas.no/2006/09/messaging/sms">
  <DeliverMessage id="72a22b0b-543f-4c2d-88f5-4e1d3e0f9288">
    <Account format="shortcode">12345</Account>
    <OA format="number">4712345678</OA>
    <DA format="shortcode">12345</DA>
    <Content>
      <Text header="050003010202">c turpis. Curabitur ac ipsum et tellus rutrum bibendum non quis ligula. Maecenas sagittis ante non orci malesuada tincidunt. In vel eros nisi.</Text>
      <DCS>0</DCS>
    </Content>
  </DeliverMessage>
</DeliverReq>

Deliver request - sub number

The following example illustrates the structure of a SMS MO message with sub-number information. The SMS MO message is the reply of an earlier SMS MT message sent from account 12345 to 4712345678. The sub-number information is 1234567890.

Example:

<DeliverReq xmlns="http://differitas.no/2006/09/messaging/sms">
  <DeliverMessage id="123420071219102054059361">
    <Account format="shortcode">12345</Account>
    <OA>4712345678</OA>
    <DA format="shortcode">12341234567890</DA>
    <Content>
      <Text header="">Test</Text>
      <DCS>3</DCS>
    </Content>
    <DeliveryTime>20070427:235900</DeliveryTime>
  </DeliverMessage>
</DeliverReq>

For information about sub-number support see section Sub-number.

Deliver response

CPA platform expects a valid Deliver response message from the Content Provider in order to determine whether a MO message has been received by the Content Provider or not.

The following XML fragment must be returned as a response to a Deliver request message.

<?xml version="1.0" encoding="UTF-8"?>
<DeliverRsp xmlns="http://differitas.no/2006/09/messaging/sms">
  <ReportMessage id="346786435">
    <Status code="200"/>
  </ReportMessage>
</DeliverRsp>

CPA platform will verify that the Deliver response message is valid according to the WSDL. Also, the CPA platform will verify that the status code is set to 200.

Note	The CPA platform will consider all responses not properly formatted or with a status code other than 200 as failed delivery. The message will be attempted redelivered after a predefined time interval.

Delivery report messages

SMS Delivery Report (DR) messages are sent using as DeliverReportReq/DeliverReportRsp message exchange.

Delivery report request

The following XML fragment illustrates a successful Delivery Report message received for a SMS MT message sent earlier.

<?xml version="1.0" encoding="UTF-8"?>
<DeliveryReportReq xmlns:tns="http://differitas.no/2006/09/messaging/sms">
  <DeliveryReportMessage id="98765 " cref="123456" type="rejected">
    <Status code="9202">Subscriber is temporarily barred</Status>
    <Account>12345</Account>
    <OA>12345</OA>
    <DA>4712345678</DA>
    <DeliveryTime>20070427:235900</DeliveryTime>
  </DeliveryReportMessage>
</DeliveryReportReq>

Information element Comment

Information element	Comment
cref	Client reference associated with the submit message
id	SMS CPA generated identification of a submitted message triggering the delivery report.
type	Deliver report type. Valid types: `retrieved` - SMS message received by mobile subscriber `rejected` - SMS message has been rejected by CPA platform `expired` – SMS message has expired upon delivery to mobile subscriber
Account	The originating account of the original SMS MT the message.
OA	The originating sender address (i.e. mobile subscriber) of the original SMS MT message.
DA	The recipient of the message (i.e. the content provider identified by short-code)
DeliveryTime	Time when message was sent by the mobile subscriber. Format: `yyyyMMdd:HHmmss` yyyy indicates the year MM indicates the month dd indicates the date HH indicates the hour using 24-hour clock mm indicates the minutes ss indicates the seconds Example: `20070427:235900`
Status	Message delivery status. For list of delivery status codes, see Delivery report status codes.
Description	Text description of the status.

cref

Client reference associated with the submit message

SMS CPA generated identification of a submitted message triggering the delivery report.

type

Deliver report type. Valid types:

retrieved - SMS message received by mobile subscriber
rejected - SMS message has been rejected by CPA platform
expired – SMS message has expired upon delivery to mobile subscriber

Account

The originating account of the original SMS MT the message.

The originating sender address (i.e. mobile subscriber) of the original SMS MT message.

The recipient of the message (i.e. the content provider identified by short-code)

DeliveryTime

Time when message was sent by the mobile subscriber. Format: yyyyMMdd:HHmmss

yyyy indicates the year
MM indicates the month
dd indicates the date
HH indicates the hour using 24-hour clock
mm indicates the minutes
ss indicates the seconds

Example: 20070427:235900

Status

Message delivery status. For list of delivery status codes, see Delivery report status codes.

Description

Text description of the status.

Delivery report response

CPA platform expects a valid DeliveryReport response messages from the Content Provider’s in order to determine whether a DR message has been received by the Content Provider or not.

The following XML fragment must be returned as a response to a DeliveryReport request message.

<?xml version="1.0" encoding="UTF-8"?>
<DeliveryReportRsp xmlns="http://differitas.no/2006/09/messaging/sms">
  <ReportMessage id="346786435">
    <Status code="200"/>
  </ReportMessage>
</DeliveryReportRsp>

CPA platform will verify that the DeliveryReport response message is valid according to the WSDL. Also, CPA platform will verify that the status code is set to 200.

Note	CPA platform will consider all responses not properly formatted or with a status code other than 200 as failed delivery. The message will be attempted redelivered after a predefined time interval.

Appendix A: Status codes

The following table lists all status codes which may be returned in response messages.

Information element	Comment
200	Successful
500	Server error

Information element

Comment

200

Successful

500

Server error

Appendix B: Delivery report status codes

Status code	Status description	Comment
200	Retrieved	The message was successfully delivered to the terminal
9001	Duplicate client reference '[cref]'	Message associated with a client reference (cref) already used by another message. Each message must be assigned with a unique client reference.
9101	Invalid destination address '[da]'
9102	Invalid originating address '[oa]'
9103	Invalid price '[price]'
9104	Invalid large account '[account]'
9105	Invalid number series '[msisdn]'	The request failed because the number does not belong to a recognized number series as assigned by NPT (Norwegian Post and Telecom Authority).
9201	Subscriber '[msisdn]' unknown	Destination address is unknown, i.e. subscriber belongs to a mobile operator not supported.
9202	Subscriber '[msisdn]' temporarily barred
9203	Subscriber '[msisdn]' permanently barred
9204	Subscriber '[msisdn]' reserved	Subscriber is reserved against receiving overcharged content
9205	Subscriber '[msisdn]' too young
9206	Illegal operator '[operatorId]'	The request failed because the subscriber belongs to another operator.
9207	Refused by service provider with reason: '[description]'	Refused by service provider.
9301	Insufficient balance '[balance]' for '[msisdn]'	Subscriber has insufficient funds
9401	Invalid message payload	Message is rejected by SMSC
9501	Reserved Sender ID	Sender ID is reserved by Sender ID Protection. Service is not allowed to use the provided Sender ID.
9502	Blocked Sender ID	Sender ID is blocked and not allowed to use. Typically used for blacklisted variants of Sender ID Protection products.
9901	Unspecified error '[error description]'	System error
9903	Invalid validity period	The submit request failed because an invalid validity period parameter (expiry time) was specified. This error typically occurs when a submit message has been queued for too long and expiry time has passed before it was submitted to SMSC.
9999	Expired	Expired message

Status code

Status description

Comment

200

Retrieved

The message was successfully delivered to the terminal

9001

Duplicate client reference '[cref]'

Message associated with a client reference (cref) already used by another message. Each message must be assigned with a unique client reference.

9101

Invalid destination address '[da]'

9102

Invalid originating address '[oa]'

9103

Invalid price '[price]'

9104

Invalid large account '[account]'

9105

Invalid number series '[msisdn]'

The request failed because the number does not belong to a recognized number series as assigned by NPT (Norwegian Post and Telecom Authority).

9201

Subscriber '[msisdn]' unknown

Destination address is unknown, i.e. subscriber belongs to a mobile operator not supported.

9202

Subscriber '[msisdn]' temporarily barred

9203

Subscriber '[msisdn]' permanently barred

9204

Subscriber '[msisdn]' reserved

Subscriber is reserved against receiving overcharged content

9205

Subscriber '[msisdn]' too young

9206

Illegal operator '[operatorId]'

The request failed because the subscriber belongs to another operator.

9207

Refused by service provider with reason: '[description]'

Refused by service provider.

9301

Insufficient balance '[balance]' for '[msisdn]'

Subscriber has insufficient funds

9401

Invalid message payload

Message is rejected by SMSC

9501

Reserved Sender ID

Sender ID is reserved by Sender ID Protection. Service is not allowed to use the provided Sender ID.

9502

Blocked Sender ID

Sender ID is blocked and not allowed to use. Typically used for blacklisted variants of Sender ID Protection products.

9901

Unspecified error '[error description]'

System error

9903

Invalid validity period

The submit request failed because an invalid validity period parameter (expiry time) was specified. This error typically occurs when a submit message has been queued for too long and expiry time has passed before it was submitted to SMSC.

9999

Expired

Expired message

Appendix C: SMS Bulk WSDL

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://differitas.no/2006/09/messaging/sms" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsa10="http://www.w3.org/2005/08/addressing" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex" name="SmsService" targetNamespace="http://differitas.no/2006/09/messaging/sms">
    <wsp:Policy wsu:Id="SmsPort_policy">
        <wsp:ExactlyOne>
            <wsp:All>
                <http:BasicAuthentication xmlns:http="http://schemas.microsoft.com/ws/06/2004/policy/http"/>
            </wsp:All>
        </wsp:ExactlyOne>
    </wsp:Policy>
    <wsdl:types>
        <xsd:schema targetNamespace="http://differitas.no/2006/09/messaging/sms/Imports">
            <xsd:import schemaLocation="smsbulk-1.xsd" namespace="http://differitas.no/2006/09/messaging/sms"/>
            <xsd:import schemaLocation="serialize.xsd" namespace="http://schemas.microsoft.com/2003/10/Serialization/"/>
        </xsd:schema>
    </wsdl:types>
    <wsdl:message name="SubmitRequest">
        <wsdl:part name="parameters" element="tns:SubmitReq"/>
    </wsdl:message>
    <wsdl:message name="SubmitResponse">
        <wsdl:part name="parameters" element="tns:SubmitRsp"/>
    </wsdl:message>
    <wsdl:message name="SmsService_Submit_ServerFault_FaultMessage">
        <wsdl:part name="detail" element="tns:ServerFault"/>
    </wsdl:message>
    <wsdl:message name="SmsService_Submit_ValidationFault_FaultMessage">
        <wsdl:part name="detail" element="tns:ValidationFault"/>
    </wsdl:message>
    <wsdl:portType name="SmsService">
        <wsdl:operation name="Submit">
            <wsdl:input wsaw:Action="http://differitas.no/2006/09/messaging/sms/SmsService/Submit" name="SubmitRequest" message="tns:SubmitRequest"/>
            <wsdl:output wsaw:Action="http://differitas.no/2006/09/messaging/sms/SmsService/SubmitResponse" name="SubmitResponse" message="tns:SubmitResponse"/>
            <wsdl:fault wsaw:Action="http://differitas.no/2006/09/messaging/sms/ServerFault" name="ServerFault" message="tns:SmsService_Submit_ServerFault_FaultMessage"/>
            <wsdl:fault wsaw:Action="http://differitas.no/2006/09/messaging/sms/ValidationFault" name="ValidationFault" message="tns:SmsService_Submit_ValidationFault_FaultMessage"/>
        </wsdl:operation>
    </wsdl:portType>
    <wsdl:binding name="SmsPort" type="tns:SmsService">
        <wsp:PolicyReference URI="#SmsPort_policy"/>
        <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>
        <wsdl:operation name="Submit">
            <soap:operation soapAction="http://differitas.no/2006/09/messaging/sms/SmsService/Submit" style="document"/>
            <wsdl:input name="SubmitRequest">
                <soap:body use="literal"/>
            </wsdl:input>
            <wsdl:output name="SubmitResponse">
                <soap:body use="literal"/>
            </wsdl:output>
            <wsdl:fault name="ServerFault">
                <soap:fault name="ServerFault" use="literal"/>
            </wsdl:fault>
            <wsdl:fault name="ValidationFault">
                <soap:fault name="ValidationFault" use="literal"/>
            </wsdl:fault>
        </wsdl:operation>
    </wsdl:binding>
    <wsdl:service name="SmsService">
        <wsdl:port name="SmsPort" binding="tns:SmsPort">
            <soap:address location="https://api.messaging.telia.no/smscallback/ws/v2"/>
        </wsdl:port>
    </wsdl:service>
</wsdl:definitions>

Appendix D: SMS Callback WSDL

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
    xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:tns="http://differitas.no/2006/09/messaging/sms"
    xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
    xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
    xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract"
    xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
    xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
    xmlns:wsa10="http://www.w3.org/2005/08/addressing"
    xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex" name="SmsCallbackService" targetNamespace="http://differitas.no/2006/09/messaging/sms">
    <wsdl:types>
        <xsd:schema targetNamespace="http://differitas.no/2006/09/messaging/sms/Imports">
            <xsd:import schemaLocation="http://cpaace.netcom.no:80/wssmsservice/smscallback?xsd=2" namespace="http://differitas.no/2006/09/messaging/sms"/>
            <xsd:import schemaLocation="http://cpaace.netcom.no:80/wssmsservice/smscallback?xsd=1" namespace="http://schemas.microsoft.com/2003/10/Serialization/"/>
        </xsd:schema>
    </wsdl:types>
    <wsdl:message name="DeliverRequest">
        <wsdl:part name="parameters" element="tns:DeliverReq"/>
    </wsdl:message>
    <wsdl:message name="DeliverResponse">
        <wsdl:part name="parameters" element="tns:DeliverRsp"/>
    </wsdl:message>
    <wsdl:message name="ValidationFault">
        <wsdl:part name="detail" element="tns:ValidationFault"/>
    </wsdl:message>
    <wsdl:message name="ServerFault">
        <wsdl:part name="detail" element="tns:ServerFault"/>
    </wsdl:message>
    <wsdl:message name="DeliveryReportRequest">
        <wsdl:part name="parameters" element="tns:DeliveryReportReq"/>
    </wsdl:message>
    <wsdl:message name="DeliveryReportResponse">
        <wsdl:part name="parameters" element="tns:DeliveryReportRsp"/>
    </wsdl:message>
    <wsdl:portType name="SmsCallbackService">
        <wsdl:operation name="DeliverMessage">
            <wsdl:input wsaw:Action="http://differitas.no/2006/09/messaging/sms/SmsCallbackService/DeliverMessage" name="DeliverRequest" message="tns:DeliverRequest"/>
            <wsdl:output wsaw:Action="http://differitas.no/2006/09/messaging/sms/SmsCallbackService/DeliverMessageResponse" name="DeliverResponse" message="tns:DeliverResponse"/>
            <wsdl:fault wsaw:Action="http://differitas.no/2006/09/messaging/sms/ValidationFault" name="ValidationFault" message="tns:ValidationFault"/>
            <wsdl:fault wsaw:Action="http://differitas.no/2006/09/messaging/sms/ServerFault" name="ServerFault" message="tns:ServerFault"/>
        </wsdl:operation>
        <wsdl:operation name="DeliverReport">
            <wsdl:input wsaw:Action="http://differitas.no/2006/09/messaging/sms/SmsCallbackService/DeliverReport" name="DeliveryReportRequest" message="tns:DeliveryReportRequest"/>
            <wsdl:output wsaw:Action="http://differitas.no/2006/09/messaging/sms/SmsCallbackService/DeliverReportResponse" name="DeliveryReportResponse" message="tns:DeliveryReportResponse"/>
            <wsdl:fault wsaw:Action="http://differitas.no/2006/09/messaging/sms/ValidationFault" name="ValidationFault" message="tns:ValidationFault"/>
            <wsdl:fault wsaw:Action="http://differitas.no/2006/09/messaging/sms/ServerFault" name="ServerFault" message="tns:ServerFault"/>
        </wsdl:operation>
    </wsdl:portType>
    <wsdl:binding name="SmsCallbackPort" type="tns:SmsCallbackService">
        <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>
        <wsdl:operation name="DeliverMessage">
            <soap:operation soapAction="http://differitas.no/2006/09/messaging/sms/SmsCallbackService/DeliverMessage" style="document"/>
            <wsdl:input name="DeliverRequest">
                <soap:body use="literal"/>
            </wsdl:input>
            <wsdl:output name="DeliverResponse">
                <soap:body use="literal"/>
            </wsdl:output>
            <wsdl:fault name="ValidationFault">
                <soap:fault name="ValidationFault" use="literal"/>
            </wsdl:fault>
            <wsdl:fault name="ServerFault">
                <soap:fault name="ServerFault" use="literal"/>
            </wsdl:fault>
        </wsdl:operation>
        <wsdl:operation name="DeliverReport">
            <soap:operation soapAction="http://differitas.no/2006/09/messaging/sms/SmsCallbackService/DeliverReport" style="document"/>
            <wsdl:input name="DeliveryReportRequest">
                <soap:body use="literal"/>
            </wsdl:input>
            <wsdl:output name="DeliveryReportResponse">
                <soap:body use="literal"/>
            </wsdl:output>
            <wsdl:fault name="ValidationFault">
                <soap:fault name="ValidationFault" use="literal"/>
            </wsdl:fault>
            <wsdl:fault name="ServerFault">
                <soap:fault name="ServerFault" use="literal"/>
            </wsdl:fault>
        </wsdl:operation>
    </wsdl:binding>
    <wsdl:service name="SmsCallbackService">
        <wsdl:port name="SmsCallbackPort" binding="tns:SmsCallbackPort">
            <soap:address location="https://api.messaging.telia.no/smscallback/ws/v2"/>
        </wsdl:port>
    </wsdl:service>
</wsdl:definitions>

Appendix E: SOAP Message Examples

SMS Submit Message

POST /smsbulk/ws/v2 HTTP/1.0
Host: api.messaging.telia.no
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://differitas.no/2006/09/messaging/sms/SmsService/Submit"
Content-Length: 391

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Body>
        <SubmitReq xmlns="http://differitas.no/2006/09/messaging/sms">
            <SubmitMessage>
                <Account>8000</Account>
                <OA>8000</OA>
                <DA>4712345678</DA>
                <Content>
                    <Text>This is a message.</Text>
                </Content>
                <Cost>0</Content>
            </SubmitMessage>
        </SubmitReq>
    </soapenv:Body>
</soapenv:Envelope>

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: 398
Connection: Close

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <SubmitRsp xmlns="http://differitas.no/2006/09/messaging/sms">
            <ReportMessage id="88b97b1d-011c-4053-a141-0c3fe0c6cbfe">
                <Status code="200">Successful</Status>
            </ReportMessage>
        </SubmitRsp>
    </s:Body>
</s:Envelope>

SMS Delivery Report Message

POST /smscallback/ws/v2 HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://differitas.no/2006/09/messaging/sms/SmsCallbackService/DeliverReport"
Host: api.messaging.telia.no
Content-Length: 509
Connection: Keep-Alive

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <DeliveryReportReq xmlns="http://differitas.no/2006/09/messaging/sms">
            <DeliveryReportMessage id="88b97b1d-011c-4053-a141-0c3fe0c6cbfe" cref="11347" type="retrieved">
                <Status code="200"/>
                <Account  format="shortcode">8000</Account>
                <OA format="shortcode">8000</OA>
                <DA>4712345678</DA>
            </DeliveryReportMessage>
        </DeliveryReportReq>
    </s:Body>
</s:Envelope>

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8

<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Body>
        <DeliveryReportRsp xmlns="http://differitas.no/2006/09/messaging/sms">
            <ReportMessage id="88b97b1d-011c-4053-a141-0c3fe0c6cbfe">
                <Status code="200"/>
            </ReportMessage>
        </DeliveryReportRsp>
    </soapenv:Body>
</soapenv:Envelope>

Appendix F: GSM 7-bit default alphabet table

Note	1) This code is an escape to an extension of this table (either to the GSM 7 bit default alphabet extension table or a National Language Single Shift Table. A receiving entity which does not understand the meaning of this escape mechanism shall display it as a space character.

GSM 7-bit default alphabet extension table

Note

In the event that an MS receives a code where a symbol is not represented in the above table then the MS shall display either the character shown in the main GSM 7 bit default alphabet table, or the character from the National Language Locking Shift Table. A receiving entity which does not understand the meaning of this escape mechanism shall display it as a space character.

Note	1) This code is reserved for the extension to another extension table.

Note

2) Void

Note	3) This code is defined as a Page Break character and may be used for example in compressed CBS messages. Any mobile station which does not understand the GSM 7 bit default alphabet table extension mechanism will treat this character as Line Feed.

Appendix G: References

”Alphabets and language-specific information”, TS 23.038 v6.0.0, October 2003
“Technical realization of the Short Message Service (SMS)”, TS 23.040, October 2003