SAP - SMS - 365-Enterprise - service-SMTP - Interface - Specification - v2

SAP SMS 365, enterprise service
SMTP Technical Specification

October 2013
SAP SMS 365, ENTERPRISE EDITION - SMTP INTERFACE
TABLE OF CONTENTS
1 INTRODUCTION ............................................................................................................................... 5
2 SENDING SMTP MESSAGES .......................................................................................................... 5
2.1 MSISDN Section ............................................................................................................................... 5
2.1.1 List ..................................................................................................................................................... 5
2.2 Message Section .............................................................................................................................. 5
2.2.1 Text .................................................................................................................................................... 6
2.2.1.1 Latin character set ............................................................................................................................. 6
2.2.1.2 Chinese character set ........................................................................................................................ 6
2.2.2 Binary ................................................................................................................................................. 6
2.2.3 Length ................................................................................................................................................ 6
2.3 Setup Section ................................................................................................................................... 7
2.3.1 Class .................................................................................................................................................. 7
2.3.2 2.3.2 DCS (Data Coding Scheme) .................................................................................................... 7
2.3.3 PID (Protocol Identifier) ..................................................................................................................... 7
2.3.4 MobileNotification .............................................................................................................................. 7
2.3.5 MailAckType ...................................................................................................................................... 7
2.3.6 ValidityPeriod ..................................................................................................................................... 8
2.3.6.1 Coding:............................................................................................................................................... 8
2.3.7 DestinationPort .................................................................................................................................. 8
2.3.8 OriginatorPort .................................................................................................................................... 9
3 DELIVERY NOTIFICATIONS .......................................................................................................... 10
3.1 Delivery Notifications Returned by the SMTP Interface ............................................................ 10
3.1.1 What is a Temporary Positive Notification Status?.......................................................................... 13
3.1.2 What is a Final Positive Notification Status? ................................................................................... 13
3.1.3 What is a Temporary Negative Notification Status? ........................................................................ 13
3.1.4 What is a Final Negative Notification Status?.................................................................................. 13
3.1.5 What is a Retriable Status? ............................................................................................................. 13
4 RECEIVING SMTP MESSAGES..................................................................................................... 14
4.1 Message Format ............................................................................................................................ 14
4.1.1 SERVICE Section ............................................................................................................................ 14
4.1.2 MSISDN Section .............................................................................................................................. 14
4.1.3 Message Section ............................................................................................................................. 14
4.1.4 Parameters Section ......................................................................................................................... 14
4.1.4.1 DCS (Data Coding Scheme)............................................................................................................ 14
4.1.4.2 ReceivedTime .................................................................................................................................. 14
4.1.4.3 Coding:............................................................................................................................................. 14
5 APPENDIX A: GSM DEFAULT ALPHABET .................................................................................. 15
6 APPENDIX B: ISO-8859-1 TO GSM 3.38 ALPHABET TRANSLATION ....................................... 16
7 APPENDIX C: CREATING BINARY CONTENT ............................................................................ 27
7.1 Ringtone Format ............................................................................................................................ 27
7.1.1 Ringtone Creation ............................................................................................................................ 27
7.1.2 RTTL ................................................................................................................................................ 28
7.1.3 MIDI ................................................................................................................................................. 28
7.1.4 Mail Transfer Format ....................................................................................................................... 28
7.1.5 Ports................................................................................................................................................. 28
7.2 Operator Logo Format ................................................................................................................... 28
7.2.1 Format Coding ................................................................................................................................. 29
7.2.2 Ports................................................................................................................................................. 29
2
7.2.3 Payload Explanation ........................................................................................................................ 29

7.2.4 Ports................................................................................................................................................. 30
7.3 Picture Messaging ......................................................................................................................... 30
7.3.1 Picture Coding ................................................................................................................................. 30
7.3.2 Adding a Text Message to the Picture ............................................................................................. 30
7.3.3 Ports................................................................................................................................................. 31
7.4 MIME vCARD .................................................................................................................................. 31
7.5 MIME vCalendar ............................................................................................................................. 31
7.6 TTML ............................................................................................................................................... 32
8 APPENDIX D: ERROR MESSAGES RETURNED DURING MESSAGE SENDING ..................... 33
9 REFERENCES ................................................................................................................................ 35
3
IMPORTANT NOTICE:
The information in this document is subject to change without notice and should not be construed as a
commitment by SAP. SAP assumes no responsibility for any errors that may appear in this document.
4
1 INTRODUCTION
The SAP SMS 365, enterprise service, SMTP interface is intended for Content Providers (CPs) connecting
into SAP messaging gateway for:
• Mobile Terminated (MT) Services

• Mobile Originated (MO) Services
Detailed explanations and samples will be given throughout the document.
2 SENDING SMTP MESSAGES

The structure of SMTP messages dispatched to SAP for onward transmission over SMS is illustrated below.
[MSISDN]
List=
[MESSAGE]
Text=
Binary=
Length=
[SETUP]
Class=
DCS=
PID=
MobileNotification=
MailAckType=
ValidityPeriod=
DestinationPort=
OriginatorPort=
[END]
Note: The SMTP message must be sent in plain-text format. An HTML email will not be allowed by the mail
server.
2.1 MSISDN Section
2.1.1 List
The MSISDN section contains the phone number(s) of the recipient(s) of the short message. The phone
number(s) shall be given in international format (i.e., “+” followed by the international country code phone
number). Phone numbers are separated by commas. The maximum number of phone numbers that can be
specified in a single request is 200. To achieve optimal performance, we recommend that you specify up to
20 phone numbers per request.
Example:
[MSISDN]
List=+44777123123,+39789432445
Note: This field is mandatory. No spaces are allowed between the comma and the phone number.
2.2 Message Section

The Message section contains either the text to be displayed on the mobile phone or binary data used for
Smart Messaging.
5
2.2.1 Text
This field specifies the text that will be sent to a mobile phone. This field is mandatory if you send a text
message, and in this case the “Binary” field should not be present. Two character sets are accepted: Latin
and Chinese (see below).
2.2.1.1 Latin character set

Coded in Latin-1 (ISO-8859-1) format, the maximum permitted length for this field is 160 characters.
All the characters defined in the ISO-8859-1 format and not permitted by the GSM 3.38 characters will be
transformed as described in Appendix B - ISO-8859-1 to GSM 3.38 alphabet translation.
Use the specific marker <LF> to insert the line feed character. The use of the <CR> (carriage return) is not
recommended, as most handsets are incompatible with this feature. The list of permitted characters is shown
in Appendix A - GSM Default Alphabet.
Example:
[MESSAGE]
Text=This is a text message. <LF> Courtesy of SAP.
Note: In this example, the text following the <LF> marker will be displayed on a new line regardless of the
width of the handset's display.
2.2.1.2 Chinese character set

Coded in BIG5, the maximum permitted length is 70 characters. The DCS field has to be specified with the
appropriate value (BIG5).
The specific markers <CR> and <LF> are also available.
Example:
[MESSAGE]
Text=¬¬¬¬
[SETUP]
DCS=BIG5
2.2.2 Binary
This field contains the binary data to be submitted, such as ringtones or logos. The maximum length is 512
bytes (i.e., 1,024 ASCII characters, spaces being omitted). Each hexadecimal value of the binary data shall
be encoded in ASCII code in order to allow the correct transfer over the Internet (see example below). This
field can also contain a Chinese message (UCS2 binary data encoded in ASCII). In this case, the DCS field
must be set to UCS2.
2.2.3 Length
The length is mandatory when binary data is submitted and is only used in this case. The length indicated is
the size of the binary data before encoding (i.e., the number of bytes).
Example:
[MESSAGE]
Binary=024A3A4000
Length=5
Note: In this example, each four-bit word of the original message is encoded in ASCII before being sent.
Example (Chinese message):

[MESSAGE]
Binary=4F60597D55CE003F
Length=8
6
[SETUP]
DCS=UCS2
Note: For Chinese messages, the DCS field must be set to UCS2. For other binary messages, the DCS will
be automatically set to 8b.
2.3 Setup Section

This section defines the parameters of the message to be sent. All fields are optional. If a field is not present,
a default value will be used.
2.3.1 Class
This field defines the class of the short message to be sent. The following are the possible values:
0: Class 0. The message will be displayed immediately on the handset, but will be erased after the first
keypad entry.
1: Class 1. The message will be displayed on the screen or stored in the SIM card, depending on the
handset.
2: Class 2. The message will be stored in the SIM card of the handset. Usually, the user will be notified with
a beep and/or an icon on the screen. This is the default value.
The Class values are described in GSM TS 03.38 [1].
2.3.2 2.3.2 DCS (Data Coding Scheme)

This field specifies how the text of the short message is encoded.
• When the message contains text, the value is automatically set to 7b (standing for 7 bits default
alphabet).
• When the message contains binary data, this field is automatically set to 8b (standing for 8 bits binary
data).
• When sending a Chinese message, this field is mandatory. The possible values are UCS2 or BIG5.
The Data Coding Scheme values are described in GSM 03.38 [1].
2.3.3 PID (Protocol Identifier)

The only permitted value is Type0, which stands for short message type 0. A short message type 0 indicates
that the mobile phone must acknowledge receipt of the short message.
2.3.4 MobileNotification
This field indicates whether a delivery notification from the handset is requested or not. The handset delivery
information is operator dependent. The possible values are Yes or No. The default value is No. See section
4 below for the set of delivery notifications returned by the SAP365 messaging gateway.
2.3.5 MailAckType
This field indicates the level of reporting that SAP will send back to the originator of the incoming message.
The following values are allowed:
Order: When this option is set, SAP will only acknowledge the receipt of the message by giving an order
identifier and the number of messages generated. This is the default value.
Message: When this option is set, SAP will return a delivery notification acknowledging the message was:
• Delivered to the operator’s SMS-C
• Delivered to the user/handset (where supported by the destination operator)
• Failed delivery
The table below summarizes the results obtained depending on the two notification options.
7
Table 1: MailAck Type Options
MailAckType Mobile Notification Result
Order No Client receives only SAP reception

notification
Yes Client receives only SAP reception

notification
Message No Client receives notification of SAP and

SMS-C reception
Yes Client receives notification of SAP and

handset reception (where the Handset Ack
is supported by the destination operator).
2.3.6 ValidityPeriod
Each short message submitted to SAP is assigned a Validity Period setting the maximum time that the short
message is retained in SAP’s network and/or in the network of the corresponding wireless operator. Failure
to deliver the short message successfully within the short message lifetime (if the subscriber is out of
coverage for instance) leads to those messages being purged.
Setting specific short message Validity Periods is important for many SMS-based applications. For example,
a daily short message informing you of a stock quotation at the end of the day would have a 24-hour Validity
Period. In this case, the information is not necessarily relevant when received a day after having been sent.
The validity period defined when sending an SMTP message to SAP is independent of the maximum validity
period allowed on each specific wireless network. The validity period is counted from the moment SAP
receives the message.
2.3.6.1 Coding:
ValidityPeriod=n [w|d|h|m]
Where:
n stands for the number of units
w stands for week
d stands for day
h stands for hour
m stands for minute
Example:
ValidityPeriod=2w ; Two weeks
ValidityPeriod=3d ; Three days
ValidityPeriod=10m ; Ten Minutes
2.3.7 DestinationPort
This field contains the receiving port used for specific applications such as Smart Messaging. This field is
mandatory when binary data is submitted and only used in this case. The hexadecimal value is sent.
Example:
DestinationPort=1581 ; Nokia Ringtones
8
2.3.8 OriginatorPort
This field contains the sending port used for specific applications like Smart Messaging. This field is
mandatory when binary data are submitted and only used in this case. The hexadecimal value is sent.
Example:
OriginatorPort=1581; Nokia Ringtones
9
3 DELIVERY NOTIFICATIONS
Delivery Notifications are message acknowledgments sent from the SAP network to customers. When
delivering messages through our network, customers can request to receive the following three levels of
acknowledgment: SAP Ack, SMS-C Ack, and Handset Ack. For unsuccessful delivery attempts, SAP will
return a negative acknowledgment (NACK) outlining the failure reason.
3.1 Delivery Notifications Returned by the SMTP Interface

The following table captures the Delivery Notifications (both Positive and Negative acknowledgments)
returned by the SAP messaging gateway.
Table 2: Delivery Notifications Returned by the SMTP Interface
Customer
Notification Notification Notification Message Sent Notification
Receives
Status Code Indicates to Customer Retriable?
(Example)
Temporary Positive
450E SAP SMS 365 Your message Your message N

Ack has been has been
correctly correctly
processed. processed. 1
<NBROFMESS message(s)
> message(s) has(have) been
have been generated with
generated with the order Id
the order Id 1887176643.
<ORDERID>.
450A SMS-C Ack, Message Message 1 of N

waiting for <MESSID> of the order
Handset Ack the order 1887176643 at
<ORDERID> at destination of
destination of +6598457560
<MSISDNNBR has been sent
> has been at 09:33:15
sent at <TIME> (CET) on the
(CET) on the 11-05-2005.
<DATE>.
Final Positive
450A SMS-C Ack, Message Message 1 of N

not waiting for <MESSID> of the order
Handset Ack the order 1887197305 at
<MSISDNNBR has been sent
> has been at 10:09:38
sent at <TIME> (CET) on the
(CET) on the 11-05-2005.
<DATE>.
10
Customer
Receives
(Example)
451A Handset Ack Message Message 1 of N

<MESSID> of the order
the order 1887176643 at
<MSISDNNBR has been
> has been received at
received at 09:33:15 (CET)
<TIME> (CET) on the 11-05-
on the 2005.
<DATE>.
Temporary Negative
DBF3 SAP is retrying <ERROR> Error dbf3: N

delivery Message Message 1 of
<MESSID> of orderid
orderid 1887176643
<ORDERID> for number
for number +6598457560:
<MSISDNNBR Mobileway
>: Mobileway retrying
retrying.
Final Negative
4524 MSISDN is Message Message 1 of N

blacklisted <MESSID> of orderid
orderid 1887176643
for number +6598457560
<MSISDNNBR has been
> has been filtered on
filtered on customer
customer request.
request.
DB05 Call barred by <ERROR> Error db05: N

operator Message Message 1 of
<MESSID> of orderid
orderid 1887176643
<MSISDNNBR rejected by
> rejected by destination
destination operator
operator.
11
Customer
Receives
(Example)
DB52 Failed <ERROR> Error db52: N

Message Message Message 1 of
Delivery <MESSID> of orderid
orderid 1887176643
> rejected by Operator
Operator.
DB76 Subscriber <ERROR> Error db76: N

profile does not Message Message 1 of
permit service <MESSID> of orderid
orderid 1887176643
> rejected by Operator.
Operator. MSISDN
MSISDN account is
account is barred.
barred.
DB99 Ported Number <ERROR> Error db99: N

Message Message 1 of
<MESSID> of orderid
orderid 1887176643
Operator.
DB62 Failed <ERROR> Error db62: Y

Message Message Message 1 of
Delivery <MESSID> of orderid
orderid 1887176643
Operator.
12
Customer
Receives
(Example)
DB65 Validity Period <ERROR> Error db65: Y

Expired Message Message 1 of
<MESSID> of orderid
orderid 1887176643
Operator.
DB78 Subscriber is <ERROR> Error db78: Y

temporarily out Message Message 1 of
of credit <MESSID> of orderid
orderid 1887176643
<MSISDNNBR does not have
> does not sufficient credit
have sufficient
credit.
3.1.1 What is a Temporary Positive Notification Status?

A temporary positive notification indicates to a customer an interim delivery confirmation, with a final delivery
confirmation yet to be returned.
3.1.2 What is a Final Positive Notification Status?

A final positive notification is returned when the message has been delivered to the operator’s SMS-C (when
no Handset Ack is requested, or the operator does not support Handset Ack) or to the handset (when a
Handset Ack is requested). In both cases, the status is final and no additional notifications will be sent for
that message.
3.1.3 What is a Temporary Negative Notification Status?

A temporary negative notification is returned when SAP is attempting a retry on a message that previously
failed to deliver. When this happens, customers should expect a final status to be sent at the conclusion of
the retry process, whether positive or negative. Until a final status is received, customers should not be
initiating their own retry, as it could potentially result in duplicate messages arriving at the handset.
3.1.4 What is a Final Negative Notification Status?

A final negative notification is returned when SAP could not deliver a particular message and will not attempt
a retry. The returned status code will indicate to the customer whether the message is retriable or not, in
which case the customer can initiate their own retry process. There are no additional notifications sent after a
final negative status.
3.1.5 What is a Retriable Status?

A retriable status means that SAP will allow the customer to retry delivery of the message, although SAP
itself will not be attempting the retry.
13
4 RECEIVING SMTP MESSAGES

This section describes the format of SMTP messages exchanged from SAP SMS 365, enterprise service, to
a third party upon reception of mobile originated short messages (SMS MO). The reception by SAP of SMS
MO at destination of a registered CP will generate an SMTP message complying with this specification.
4.1 Message Format

Below is the framework of the body of the SMTP messages sent by SAP:
[SERVICE]
Destination=
[MSISDN]
Phone=
[MESSAGE]
Text=
[PARAMETERS]
DCS=
ReceivedTime=
4.1.1 SERVICE Section

The SERVICE section contains the phone number or the shortcode of the destination of the SMS. The
destination is a phone number given in international format (i.e., “+” International Country Code Phone
Number).
4.1.2 MSISDN Section

The MSISDN section contains the phone number of the originator of the SMS. The phone number is given in
international format (i.e., “+” International Country Code Phone Number).
Example:
[MSISDN]
Phone=+44777123123
4.1.3 Message Section

The Message section contains the text sent by the mobile subscriber. The maximum length for this field is
160 characters when using DCS=7b.
The specific markers <CR> (carriage return) and <LF> (line feed) are used to insert the special characters.
4.1.4 Parameters Section

This section shows parameters of the message sent by the mobile subscriber.
4.1.4.1 DCS (Data Coding Scheme)

This field specifies how the text of the short message is encoded. The value is given in decimal format. The
Data Coding Scheme values are described in GSM 03.38 [1].
4.1.4.2 ReceivedTime
This field contains the reception date and time of the short message by SAP's network.
4.1.4.3 Coding:
ReceivedTime=ddd, dd mm yyyy hh:mm:ss +GMT
Where
ddd stands for day (Mon)
dd stands for day
mm stands for month
yyyy stands for year
hh stands for hour
mm stands for minute
14
ss stands for second
Example:
ReceivedTime= Wed, 3 Jul 2001 20:37:19 +0100
5 APPENDIX A: GSM DEFAULT ALPHABET

The following list shows all authorized characters in a SMS message according to the GSM 03.38
specification. Some of these characters may not be available on all networks. The message text shall be
coded using the Latin-1 format (ISO-8859-1).
@ SP 0 i P ¿ p
£ ! 1 A Q a q
$ “ 2 B R b r
¥ # 3 C S c s
è ¤ 4 D T d t
é % 5 E U e u
ù & 6 F V f v
ì ‘ 7 G W g w
ò ( 8 H X h x
(1)
) 9 I Y i y
Ç
LF * : J Z j z
Ø + ; K Ä k ä
ø , < L Ö l ö
CR - = M Ñ m ñ
Å . > N Ü n ü
å / ? O § o à
(1) This character is uppercase. The lowercase version of this character is not accepted by the GSM
3.38 specification.
15
6 APPENDIX B: ISO-8859-1 TO GSM 3.38 ALPHABET TRANSLATION

An automatic translation is done when an unauthorized character is given in the text message. All the
information of this translation is given in the ISO-8859-1 character set table below.
Ch Dec Hex Description GSM 3.38
Default 032 20 Space No change
! 033 21 Exclamation Point No change
" 034 22 Double Quote No change
# 035 23 Number/Pound No change
$ 036 24 Dollars No change
% 037 25 Percent No change
& 038 26 Ampersand No change
' 039 27 Single Quote No change
( 040 28 Left Parenthesis No change
) 041 29 Right Parenthesis No change
* 042 2a Asterisk No change
+ 043 2b Plus No change
, 044 2c Comma No change
- 045 2d Hyphen No change
. 046 2e Period No change
/ 047 2f Forward Slash No change
0 048 30 Digit 0 No change
16
: 058 3a Colon No change
; 059 3b Semicolon No change
< 060 3c Less Than No change
= 061 3d Equals No change
> 062 3e Greater Than No change
? 063 3f Question Mark No change
@ 064 40 Commercial At No change
A 065 41 Uppercase A No change
B 066 42 Uppercase B No change
C 067 43 Uppercase C No change
D 068 44 Uppercase D No change
E 069 45 Uppercase E No change
F 070 46 Uppercase F No change
G 071 47 Uppercase G No change
17
H 072 48 Uppercase H No change
I 073 49 Uppercase I No change
J 074 4a Uppercase J No change
K 075 4b Uppercase K No change
L 076 4c Uppercase L No change
M 077 4d Uppercase M No change
N 078 4e Uppercase N No change
O 079 4f Uppercase O No change
P 080 50 Uppercase P No change
Q 081 51 Uppercase Q No change
R 082 52 Uppercase R No change
S 083 53 Uppercase S No change
T 084 54 Uppercase T No change
U 085 55 Uppercase U No change
V 086 56 Uppercase V No change
W 087 57 Uppercase W No change
X 088 58 Uppercase X No change
Y 089 59 Uppercase Y No change
Z 090 5a Uppercase Z No change
[ 091 5b Left Bracket No change
\ 092 5c Backslash /
18
] 093 5d Right Bracket No change
^ 094 5e Caret (Circonflex) No change
_ 095 5f Underscore -
` 096 60 ASCII Grave '
a 097 61 Lowercase a No change
b 098 62 Lowercase b No change
c 099 63 Lowercase c No change
d 100 64 Lowercase d No change
e 101 65 Lowercase e No change
f 102 66 Lowercase f No change
g 103 67 Lowercase g No change
h 104 68 Lowercase h No change
i 105 69 Lowercase i No change
j 106 6a Lowercase j No change
k 107 6b Lowercase k No change
l 108 6c Lowercase l No change
m 109 6d Lowercase m No change
n 110 6e Lowercase n No change
o 111 6f Lowercase o No change
p 112 70 Lowercase p No change
q 113 71 Lowercase q No change
19
r 114 72 Lowercase r No change
s 115 73 Lowercase s No change
t 116 74 Lowercase t No change
u 117 75 Lowercase u No change
v 118 76 Lowercase v No change
w 119 77 Lowercase w No change
x 120 78 Lowercase x No change
y 121 79 Lowercase y No change
z 122 7a Lowercase z No change
{ 123 7b Left Curly Bracket (
| 124 7c Broken Vertical Bar /
} 125 7d Right Curly Bracket )
~ 126 7e Tilde -
€ 128 80 (unassigned) E
129 81 (unassigned) Space
‚ 130 82 (unassigned) Space
ƒ 131 83 (unassigned) Space
„ 132 84 (unassigned) Space
… 133 85 (unassigned) Space
† 134 86 (unassigned) Space
‡ 135 87 (unassigned) Space
20
ˆ 136 88 (unassigned) Space
‰ 137 89 (unassigned) Space
Š 138 8a (unassigned) Space
‹ 139 8b (unassigned) Space
Œ 140 8c (unassigned) Space
141 8d (unassigned) Space
Ž 142 8e (unassigned) Z
143 8f (unassigned) Space
144 90 (unassigned) Space
‘ 145 91 (unassigned) Space
’ 146 92 (unassigned) Space
“ 147 93 (unassigned) Space
” 148 94 (unassigned) Space
• 149 95 (unassigned) Space
– 150 96 (unassigned) Space
— 151 97 (unassigned) Space
˜ 152 98 (unassigned) Space
™ 153 99 (unassigned) Space
š 154 9a (unassigned) Space
› 155 9b (unassigned) Space
œ 156 9c (unassigned) Space
21
157 9d (unassigned) Space
ž 158 9e (unassigned) z
Ÿ 159 9f (unassigned) Y
160 a0 Hard space Space
¡ 161 a1 Inverted Exclamation No change

Point
¢ 162 a2 Cent c
£ 163 a3 Pound/Sterling No change
¤ 164 a4 General Currency No change

Symbol
¥ 165 a5 Yen No change
¦ 166 a6 Broken Vertical Bar I
§ 167 a7 Section Sign No change
¨ 168 a8 Diaeresis Space
© 169 a9 Copyright C
ª 170 aa Feminine Spanish Space

Ordinal
« 171 ab Left Double Guillemet "
¬ 172 ac Logical Not Space
® 174 ae Registered Trademark R
¯ 175 af Beginning of Line Space
° 176 b0 Ring Space
± 177 b1 Plus or Minus Space
² 178 b2 Power of 2 Space
22
³ 179 b3 Power of 3 Space
´ 180 b4 Acute Space
µ 181 b5 mu Space
¶ 182 b6 Paragraph Sign Space
• 183 b7 Small Centre Dot Space
¸ 184 b8 Cedilla Space
¹ 185 b9 Power of 1 Space
º 186 ba Masculine Spanish Space

Ordinal
» 187 bb Right Double "

Guillemet
¼ 188 bc 1/4 Space
½ 189 bd 1/2 Space
¾ 190 be 3/4 Space
¿ 191 bf Inverted Question No change

Mark
À 192 c0 A Grave A
Á 193 c1 A Acute A
Â 194 c2 A Circumflex A
Ã 195 c3 A Tilde A
Ä 196 c4 A Diaeresis No change
Å 197 c5 A Ring No change
Æ 198 c6 AE Digraph No change
Ç 199 c7 C Cedilla No change
23
È 200 c8 E Grave E
É 201 c9 E Acute No change
Ê 202 ca E Circumflex E
Ë 203 cb E Diaeresis E
Ì 204 cc I Grave I
Í 205 cd I Acute I
Î 206 ce I Circumflex I
Ï 207 cf I Diaeresis I
Ð 208 d0 Uppercase Eth Space
Ñ 209 d1 N Tilde No change
Ò 210 d2 O Grave O
Ó 211 d3 O Acute O
Ô 212 d4 O Circumflex O
Õ 213 d5 O Tilde O
Ö 214 d6 O Diaeresis No change
× 215 d7 Multiply (x) *
Ø 216 d8 O Slash No change
Ù 217 d9 U Grave U
Ú 218 da U Acute U
Û 219 db U Circumflex U
Ü 220 dc U Diaeresis No change
24
Ý 221 dd Y Acute Y
Þ 222 de Uppercase Thorn Space
ß 223 df German Double s No change
à 224 e0 a Grave No change
á 225 e1 a Acute a
â 226 e2 a Circumflex a
ã 227 e3 a Tilde a
ä 228 e4 a Diaeresis No change
å 229 e5 a Ring No change
æ 230 e6 ae Digraph No change
ç 231 e7 c Cedilla Ç
è 232 e8 e Grave No change
é 233 e9 e Acute No change
ê 234 ea e Circumflex e
ë 235 eb e Diaeresis e
ì 236 ec i Grave No change
í 237 ed i Acute i
î 238 ee i Circumflex i
ï 239 ef i Diaeresis i
ð 240 f0 Lowercase Eth o
ñ 241 f1 n Tilde No change
25
ò 242 f2 o Grave No change
ó 243 f3 o Acute o
ô 244 f4 o Circumflex o
õ 245 f5 o Tilde o
ö 246 f6 o Diaeresis No change
÷ 247 f7 Division /
ø 248 f8 o Slash No change
ù 249 f9 u Grave No change
ú 250 fa u Acute u
ü 252 fc u Diaeresis No change
ý 253 fd y Acute y
þ 254 fe Lowercase Thorn Space
ÿ 255 ff y Diaeresis y
26
7 APPENDIX C: CREATING BINARY CONTENT

7.1 Ringtone Format
The conversion process depends on the source of the ringtone format used. For Nokia phones, Midi or RTTL
formats may be used as the source format. The output format for SMS is the OTA format.
7.1.1 Ringtone Creation

With the Nokia Data Suite, launch the PC Composer tool and create/edit the desired ringtone(s) with it.
When ready, save it as an “.ott” message. When viewed with a hex format editor, the resulting file should
look something like the following:
024A3A51D195CDD008001B205505906105605585505485408208499000
The first 3 bytes code the smart messaging ringtones command information:
• 02 stands for 2 command parts
• 4A stands for the first command part: ringtone programming
• 3A stands for the second command part: sound
The subsequent few bytes encode the song title (name of the .ott file), while the remaining bytes encode the
ringtone content as follows:
Bit string Description Value
01 <basic song type>
0100 <song title length> 4 characters (ISO-8859-1)
01110100 The first character T
01100101 The second character E
0111001 The third character S
01110100 The fourth character T
00000010 <song sequence length> 2 song patterns
000 <pattern header> Pattern header id
00 <pattern id> A-part
0000 <loop value> no loop
00001101 <pattern specifier> <length of the new pattern> 13 pattern

instructions
100 <tempo instruction id>
27
Bit string Description Value
10000 <beats per minute> 160 (i.e. length of 1/4 note = 0,38 sec.)
001 <note instruction id>
0101 <note value> note E
010 <note duration> ¼ note
00 <note duration specifier> no special duration
001 <note instruction id>
...... ........ .........
0000000 <command end>
7.1.2 RTTL
If the RTTL format is being used as the source format. The file will need to be converted to the MIDI format.
7.1.3 MIDI
The MIDI file needs to be converted to an OTA file before being sent over SMS. Nokia PC Composer found
in Nokia Data Suite 3.0 includes a MIDI-to-OTA converter.
Note: Thirty-second notes from a MIDI file are replaced by eighteen-second notes in the OTA file. The tempo
of the music may also be modified.
To test the resulting ringtone with different mobile phones, use the phone’s serial cable or infrared link and
the Data Suite compatible with the target phone. This allows you to test the ringtone quality or length without
actually sending it over SMS.
If variations are noticed between MIDI and OTA files, you can modify either of them using the Nokia PC
Composer music editor.
7.1.4 Mail Transfer Format

Before sending the OTA file through SMTP, it has to be converted to ASCII-coded hexadecimal format.
7.1.5 Ports
For this application, both the originating port and destination port values are 1581. The length value depends
on the length of the ringtone.
7.2 Operator Logo Format

The operator logo can be sent over SMS using the binary field, the specific originating port and the
destination port.
28
7.2.1 Format Coding

The NLM format looks like the following:
4E4C4D20010000480E0100000000000000000000000000000000000000000000000000000000000000038
0000000000000001C4000000000000003E0200000000001FFFC0020018000000600000010024000000000
000010044000000000000010183000000000000010E0300000000000000F00100000000000000000100000
0000000000001000
The first six bytes relate to the NLM coding. These bytes are removed by the LOGOTOASCII utility. The
subsequent bytes form the PDU of the OTA bitmap. Inside this PDU, the first 4 bytes (the blue text above)
contain bitmap data information.
The first byte ("00") is the info-field of the smart messaging.

The second byte ("48"), meaning 72 in decimal, is the pixel width of the bitmap.
The third byte ("0E"), meaning 12 in decimal, is the pixel height of the bitmap.
An operator logo bitmap is always 72*12 pixels.
The fourth byte is the depth of the bitmap (the number of gray scales).
All subsequent bytes encode the OTA bitmap data.
Three other bytes must be added in front of the OTA PDU (following the Smart Messaging Specifications
document from Nokia) – they encode the operator’s information.
The first two bytes indicate the MCC (Mobile Country Code) of the operator.
The third byte indicates the MNC (Mobile Network Code) of the operator.
Each of these three bytes is coded in little-endian BCD filled with "F."
For example, if the operator MCC = 208 and its MNC = 01, the three coded bytes are "02F810."
The PDU corresponding is then the following:
02F81000480E01000000000000000000000000000000000000000000000000000000000000000380000000
000000001C4000000000000003E0200000000001FFFC00200180000006000000100240000000000000100
44000000000000010183000000000000010E0300000000000000F001000000000000000001000000000000
000001000
7.2.2 Ports
For this application, both the originating port and destination port values are 1582. The length value is
always 133.
7.2.3 Payload Explanation

The NLM format looks like this:
4E4C4D20010000480E0100000000000000000000000000000000000000000000000000000000000000038
0000000000000001C4000000000000003E0200000000001FFFC0020018000000600000010024000000000
000010044000000000000010183000000000000010E0300000000000000F00100000000000000000100000
0000000000001000
The first six bytes provide the NLM coding. These bytes are removed by LOGOTOASCII utility.
The subsequent bytes form the PDU of the OTA bitmap. Inside this PDU, the four first bytes (the blue text
above) contain bitmap data information.
The second byte ("48"), meaning 72 in decimal, is the width of the bitmap.
The third byte ("0E"), meaning 12 in decimal, is the height of the bitmap.
A caller group logo bitmap is always 72*12 pixels.
All subsequent bytes form the OTA bitmap data.
No other bytes need to be added in front of the OTA PDU. The overall PDU is therefore the following:
00480E01000000000000000000000000000000000000000000000000000000000000000380000000000000
001C4000000000000003E0200000000001FFFC00200180000006000000100240000000000000100440000
29
00000000010183000000000000010E0300000000000000F001000000000000000001000000000000000001
000
7.2.4 Ports
For this application, both the originating port and destination port values are 1583. The length value is
always 130.
7.3 Picture Messaging

Picture messaging is a Smart Messaging feature defined in the Smart Messaging Specifications and in the
Graphic Message Services (GMS) documents.
Picture messaging is based on the transmission of a 72*24 pixel picture (i.e., larger than the operator logo or
CLI one) together with an associated text (maximum 120 characters). It requires therefore the formatting of
both the picture and text, and assembling them together in a long binary sequence.
A picture messaging message is always longer than one short message.
7.3.1 Picture Coding
An example of payload format is:

00481C01000000000000000000000000100000000000000000107E0000000000000039FF8000000000000
03BFF800000000000003FFFC00000000000003FF3C00000000000007FF3800000000000007FFF8000000
00000007FFFC0000000000000F7FFC0000000000000C7FFC000000000000103FF80101000000000000C6
39E53924E4800000AA4515452414800000AA45157D54F4800000924515415514800000924515448913000
0008239E53888F200000000000000000200000000000000000C000
Inside this PDU, the first 4 bytes (the blue text above) provide bitmap data information.
The second byte ("48"), meaning 72 in decimal, is the width of the bitmap.
The third byte ("1C"), meaning 24 in decimal, is the height of the bitmap.
A picture messaging bitmap is always 72*24 pixels.
All subsequent bytes form the OTA bitmap data.
Four other bytes must be added in front of the OTA PDU (following the Graphic Message Services document
from Nokia), which encode the GMS header.
The first byte indicates the GMS version  "30."
The second byte indicates the type of the GMS item. OTA bitmap in the picture messaging stands for "02."
The following two bytes indicate the size of the bitmap. For picture messaging, it is always 256 bytes 
"0100."
The resulting overall PDU is therefore the following:
3002010000481C01000000000000000000000000100000000000000000107E0000000000000039FF80000
0000000003BFF800000000000003FFFC00000000000003FF3C00000000000007FF3800000000000007FF
F80000000000000000000000000000000000000820105000000000000820101000000000000C6010100000
0000000C639E53924E4800000AA4515452414800000AA45157D54F480000092451541551480000092451
54489130000008239E53888F200000000000000000200000000000000000C000
7.3.2 Adding a Text Message to the Picture

The coding of the message is the common ASCII representation of the text. In order to add text to the
picture, the GMS header must come before the ASCII coding of the text.
The GMS header is coded as follows:

The first byte stands for the GMS version: ”30.”
The second byte stands for the type of GMS item: “00” for ISO-8859-1 char.
The two other bytes indicate the length of the text (in bytes).
When text is added to the picture message, it must be added in front of the OTA bitmap. Moreover, the GMS
version is only indicated one time in the message (relates to the two GMS items).
For example, if we add the text “AAA” to the previous picture, the message will become the following:
3000000341414102010000481C01000000000000000000000000100000000000000000107E000000000000
0039FF800000000000003BFF800000000000003FFFC00000000000003FF3C00000000000007FF3800000
30
00000000000000000000000000000000000000000000000000820105000000000000820101000000000000
C60101000000000000C639E53924E4800000AA4515452414800000AA45157D54F4800000924515415514
8000009245154489130000008239E53888F200000000000000000200000000000000000C000
The GMS version is the first byte.
The three following bytes encode the first GMS item (i.e., the text) noted in red.
The ASCII coded text follows.
After the text, is the GMS header (composed of three bytes noted in red) of the picture.
Finally the 256 bytes of the picture itself appear at the end of the message.
7.3.3 Ports
For this application, both the originating port and destination port values are 158A.
7.4 MIME vCARD

With a text editor, prepare the phone book entry with the following encoding format (see Smart Massaging
Specifications [3]):
BEGIN:VCARD
N:<surname firstname>
TEL:+<international phone number>
END:VCARD
For example :
BEGIN:VCARD
N:SAP Mobile Services
TEL:+1555123456
END:VCARD
This message must be translated in hexadecimal ASCII format and forms the PDU to be sent. For this
application, both the originating port and destination port values are 00E2.
7.5 MIME vCalendar

With a text editor, prepare the calendar entry with the following encoding format (see Smart Massaging
Specifications [3]):
BEGIN: VCALENDAR
VERSION:1.0
BEGIN:EVENT
DESCRIPTION:<text>
DTSTART:<date>T<time>
DTEND: <date>T<time>
AALARM: <date>T<time>;;;
END:VEVENT
END:VCALENDAR
For example :
BEGIN:VCALENDAR
VERSION:1.0
BEGIN:EVENT
DESCRIPTION:SAP Mobile Services meeting
DTSTART:20000906T090000
DTEND:20000906T120000
AALARM:20000906T084500;;;
END:VEVENT
END:VCALENDAR
This message must be translated in hexadecimal ASCII format and forms the PDU to be sent.
31
For this application, both the originating port and destination port values are 00E4.
7.6 TTML
TTML specifies downlink messages (from server to mobile) and uplink messages (from mobile to server).
Concatenation of downlink messages is supported, but uplink TTML requests must be sent with only one
SM.
A TTML format always has the following syntax:

..page name
Message to appear on the mobile phone
.>Question
.>*choice_1
.>*choice_2
.>*choice_x
<<question with digit answer
<question with alphanumeric entry
><Rmessage appearing for sending form
Note: the ><R symbol used in the last line is for sending back the form.
In the following example, the customer is given several choices from which (s)he needs to make a selection
before sending the form back.
..Example in TTML
Have time for a few questions ?
>.Choose your service :

.>*Weather info
.>*Traffic info
.>*Flight info
<<Enter your code :
><Rready to send the form ?
This message just has to be converted in hexadecimal ASCII format and forms the PDU to be sent.For this
application, both the originating port and destination port values are 15CC.
32
8 APPENDIX D: ERROR MESSAGES RETURNED DURING MESSAGE SENDING
Value Message Text What to do?
5001 5001 Server currently unavailable to process your send an email to

message, please try later. service.desk@sybase.com





600F 600F Authentication failure send an email to

service.desk@sybase.com
6010 6010 Bad format for field DCS in section SETUP. check syntax of DCS field
6011 6011 Bad format for field PID in section SETUP. check syntax of PID field
6012 6012 Bad format for field MobileNotify in section SETUP. check syntax of MobileNotify
field
6013 6013 Bad format for field MailAckType in section SETUP. check syntax of MailAckType
field
6017 6017 Bad format or missing mandatory value for field Text Text or Binary field must be
in section MESSAGE. fulfilled
6018 6018 Bad format or missing mandatory value for field List in List field must be fulfilled
section MSISDN.
6019 6019 Bad format for field List in section MSISDN. check syntax of MSISDN field
(coma separated)
601A 601A Bad format for field Class in section SETUP. check syntax of Class field
6024 6024 Bad format for field ValidityPeriod in section SETUP. check syntax of ValidityPeriod
field
6026 6026 Bad format or missing mandatory value for field DestinationPort= empty field
DestinationPort in section SETUP.
33
Value Message Text What to do?
6028 6028 Bad format or missing mandatory value for field must have Length when Binary
Length in section MESSAGE. field
6029 6029 Bad format or missing mandatory value for field binary message must be
Binary in section MESSAGE. prepended by Binary=
602A 602A The message contained an invalid character. check the message compared
to GSM 3.38 table
602B 602B The message contained a an invalid binary string compare the length of binary
length. field and Length=
6030 6030 Error when processing the message. send an email to

service.desk@sybase.com
6100 6100 Error when processing the message. check message syntax
8000 8000 Server currently unavailable to process your message send an email to
please try later. service.desk@sybase.com
34
9 REFERENCES
[1] GSM TS 03.38: Digital cellular telecommunications system (Phase 2+); Alphabets and language-specific
information (GSM 03.38 version 5.5.1)
[2] GSM TS 03.40: Digital cellular telecommunications system (Phase 2+); Technical realization of the Short
Message Service (SMS); Point-to-Point (PP) (GSM 03.40 version 5.7.1)
[3] Smart Messaging Specification, Revision 2.0.0 – Nokia Mobile Phones Ltd
[4] Graphic Message Service Syntax, Revision 1.0.0 – Nokia Mobile Phones Ltd
Nokia FAQ: http://www.forum.nokia.com/
35
www.sap.com
© 2013 SAP AG or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any

form or for any purpose without the express permission of SAP AG.
The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain

proprietary software components of other software vendors. National product
specifications may vary.
These materials are provided by SAP AG and its affiliated companies (“SAP
Group”) for informational purposes only, without representation or warranty of
any kind, and SAP Group shall not be liable for errors or omissions with
respect to the materials. The only warranties for SAP Group products and
services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be
construed as constituting an additional warranty.
SAP and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG in
Germany and other countries.
Please see
http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark
for additional trademark information and notices.

SAP - SMS - 365-Enterprise - service-SMTP - Interface - Specification - v2

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SAP - SMS - 365-Enterprise - service-SMTP - Interface - Specification - v2

Hochgeladen von

Copyright:

Verfügbare Formate

SAP SMS 365, enterprise service

SMTP Technical Specification

7.2.3 Payload Explanation ........................................................................................................................ 29

• Mobile Terminated (MT) Services

Detailed explanations and samples will be given throughout the document.

2 SENDING SMTP MESSAGES

2.1 MSISDN Section

2.2 Message Section

2.2.1.1 Latin character set

2.2.1.2 Chinese character set

The specific markers <CR> and <LF> are also available.

Example (Chinese message):

2.3 Setup Section

The Class values are described in GSM TS 03.38 [1].

2.3.2 2.3.2 DCS (Data Coding Scheme)

2.3.3 PID (Protocol Identifier)

Table 1: MailAck Type Options

MailAckType Mobile Notification Result

Order No Client receives only SAP reception

Yes Client receives only SAP reception

Message No Client receives notification of SAP and

Yes Client receives notification of SAP and

3.1 Delivery Notifications Returned by the SMTP Interface

Table 2: Delivery Notifications Returned by the SMTP Interface

450E SAP SMS 365 Your message Your message N

450A SMS-C Ack, Message Message 1 of N

450A SMS-C Ack, Message Message 1 of N

451A Handset Ack Message Message 1 of N

DBF3 SAP is retrying <ERROR> Error dbf3: N

4524 MSISDN is Message Message 1 of N

DB05 Call barred by <ERROR> Error db05: N

DB52 Failed <ERROR> Error db52: N

DB76 Subscriber <ERROR> Error db76: N

DB99 Ported Number <ERROR> Error db99: N

DB62 Failed <ERROR> Error db62: Y

DB65 Validity Period <ERROR> Error db65: Y

DB78 Subscriber is <ERROR> Error db78: Y

3.1.1 What is a Temporary Positive Notification Status?

3.1.2 What is a Final Positive Notification Status?

3.1.3 What is a Temporary Negative Notification Status?

3.1.4 What is a Final Negative Notification Status?

3.1.5 What is a Retriable Status?

4 RECEIVING SMTP MESSAGES

4.1 Message Format

4.1.1 SERVICE Section

4.1.2 MSISDN Section

4.1.3 Message Section

4.1.4 Parameters Section

4.1.4.1 DCS (Data Coding Scheme)

ss stands for second

5 APPENDIX A: GSM DEFAULT ALPHABET

6 APPENDIX B: ISO-8859-1 TO GSM 3.38 ALPHABET TRANSLATION

Ch Dec Hex Description GSM 3.38

Default 032 20 Space No change

! 033 21 Exclamation Point No change

" 034 22 Double Quote No change

# 035 23 Number/Pound No change

$ 036 24 Dollars No change

% 037 25 Percent No change

& 038 26 Ampersand No change

' 039 27 Single Quote No change

( 040 28 Left Parenthesis No change

) 041 29 Right Parenthesis No change