SAP SMS 365, enterprise service SMTP Technical Specification October 2013

Transcription

1 SAP SMS 365, enterprise service SMTP Technical Specification October 2013

2 TABLE OF CONTENTS 1 INTRODUCTION SENDING SMTP MESSAGES MSISDN Section List Message Section Text Latin character set Chinese character set Binary Length Setup Section Class DCS (Data Coding Scheme) PID (Protocol Identifier) MobileNotification MailAckType ValidityPeriod Coding: DestinationPort OriginatorPort DELIVERY NOTIFICATIONS Delivery Notifications Returned by the SMTP Interface What is a Temporary Positive Notification Status? What is a Final Positive Notification Status? What is a Temporary Negative Notification Status? What is a Final Negative Notification Status? What is a Retriable Status? RECEIVING SMTP MESSAGES Message Format SERVICE Section MSISDN Section Message Section Parameters Section DCS (Data Coding Scheme) ReceivedTime Coding: APPENDIX A: GSM DEFAULT ALPHABET APPENDIX B: ISO TO GSM 3.38 ALPHABET TRANSLATION APPENDIX C: CREATING BINARY CONTENT Ringtone Format Ringtone Creation RTTL MIDI Mail Transfer Format Ports Operator Logo Format Format Coding Ports

3 7.2.3 Payload Explanation Ports Picture Messaging Picture Coding Adding a Text Message to the Picture Ports MIME vcard MIME vcalendar TTML APPENDIX D: ERROR MESSAGES RETURNED DURING MESSAGE SENDING REFERENCES

4 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

5 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 will not be allowed by the mail server. 2.1 MSISDN Section 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= , 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

6 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) Latin character set Coded in Latin-1 (ISO ) format, the maximum permitted length for this field is 160 characters. All the characters defined in the ISO format and not permitted by the GSM 3.38 characters will be transformed as described in Appendix B - ISO 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 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=BIG 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 UCS 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

7 [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 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 [1] 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 [1] 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 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 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

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

9 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

10 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 Notification Status Notification Code Notification Indicates Message Sent to Customer Customer Receives (Example) Notification Retriable? Temporary Positive 450E SAP SMS 365 Ack Your message has been correctly processed. <NBROFMESS > message(s) have been generated with the order Id <ORDERID>. Your message has been correctly processed. 1 message(s) has(have) been generated with the order Id N 450A SMS-C Ack, waiting for Handset Ack Message <MESSID> of the order <ORDERID> at destination of <MSISDNNBR > has been sent at <TIME> (CET) on the <DATE>. Message 1 of the order at destination of has been sent at 09:33:15 (CET) on the N Final Positive 450A SMS-C Ack, not waiting for Handset Ack Message <MESSID> of the order <ORDERID> at destination of <MSISDNNBR > has been sent at <TIME> (CET) on the <DATE>. Message 1 of the order at destination of has been sent at 10:09:38 (CET) on the N 10

11 Notification Status Notification Code Notification Indicates Message Sent to Customer Customer Receives (Example) Notification Retriable? 451A Handset Ack Message <MESSID> of the order <ORDERID> at destination of <MSISDNNBR > has been received at <TIME> (CET) on the <DATE>. Message 1 of the order at destination of has been received at 09:33:15 (CET) on the N Temporary Negative DBF3 SAP is retrying delivery <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR >: Mobileway retrying. Error dbf3: Message 1 of orderid for number : Mobileway retrying N Final Negative 4524 MSISDN is blacklisted Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > has been filtered on customer request. Message 1 of orderid for number has been filtered on customer request. N DB05 Call barred by operator <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > rejected by destination operator. Error db05: Message 1 of orderid for number rejected by destination operator N 11

12 Notification Status Notification Code Notification Indicates Message Sent to Customer Customer Receives (Example) Notification Retriable? DB52 Failed Message Delivery <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > rejected by Operator. Error db52: Message 1 of orderid for number rejected by Operator N DB76 Subscriber profile does not permit service <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > rejected by Operator. MSISDN account is barred. Error db76: Message 1 of orderid for number rejected by Operator. MSISDN account is barred. N DB99 Ported Number <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > rejected by Operator. Error db99: Message 1 of orderid for number rejected by Operator N DB62 Failed Message Delivery <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > rejected by Operator. Error db62: Message 1 of orderid for number rejected by Operator Y 12

13 Notification Status Notification Code Notification Indicates Message Sent to Customer Customer Receives (Example) Notification Retriable? DB65 Validity Period Expired <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > rejected by Operator. Error db65: Message 1 of orderid for number rejected by Operator Y DB78 Subscriber is temporarily out of credit <ERROR> Message <MESSID> of orderid <ORDERID> for number <MSISDNNBR > does not have sufficient credit. Error db78: Message 1 of orderid for number does not have sufficient credit Y 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 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 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 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 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

14 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= 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) 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= 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 Parameters Section This section shows parameters of the message sent by the mobile subscriber 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 [1] ReceivedTime This field contains the reception date and time of the short message by SAP's network 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

15 ss stands for second Example: ReceivedTime= Wed, 3 Jul :37: APPENDIX A: GSM DEFAULT ALPHABET The following list shows all authorized characters in a SMS message according to the GSM specification. Some of these characters may not be available on all networks. The message text shall be coded using the Latin-1 format 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

16 6 APPENDIX B: ISO 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 character set table below. Ch Dec Hex Description GSM 3.38 Default Space No change! Exclamation Point No change " Double Quote No change # Number/Pound No change $ Dollars No change % Percent No change & Ampersand No change ' Single Quote No change ( Left Parenthesis No change ) Right Parenthesis No change * 042 2a Asterisk No change b Plus No change, 044 2c Comma No change d Hyphen No change e Period No change / 047 2f Forward Slash No change Digit 0 No change Digit 1 No change Digit 2 No change 16

17 Ch Dec Hex Description GSM Digit 3 No change Digit 4 No change Digit 5 No change Digit 6 No change Digit 7 No change Digit 8 No change Digit 9 No change : 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 Commercial At No change A Uppercase A No change B Uppercase B No change C Uppercase C No change D Uppercase D No change E Uppercase E No change F Uppercase F No change G Uppercase G No change 17

18 Ch Dec Hex Description GSM 3.38 H Uppercase H No change I 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 Uppercase P No change Q Uppercase Q No change R Uppercase R No change S Uppercase S No change T Uppercase T No change U Uppercase U No change V Uppercase V No change W Uppercase W No change X Uppercase X No change Y Uppercase Y No change Z 090 5a Uppercase Z No change [ 091 5b Left Bracket No change \ 092 5c Backslash / 18

19 Ch Dec Hex Description GSM 3.38 ] 093 5d Right Bracket No change ^ 094 5e Caret (Circonflex) No change _ 095 5f Underscore - ` ASCII Grave ' a Lowercase a No change b Lowercase b No change c Lowercase c No change d Lowercase d No change e Lowercase e No change f Lowercase f No change g Lowercase g No change h Lowercase h No change i 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 Lowercase p No change q Lowercase q No change 19

20 Ch Dec Hex Description GSM 3.38 r Lowercase r No change s Lowercase s No change t Lowercase t No change u Lowercase u No change v Lowercase v No change w Lowercase w No change x Lowercase x No change y 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 (unassigned) E (unassigned) Space (unassigned) Space ƒ (unassigned) Space (unassigned) Space (unassigned) Space (unassigned) Space (unassigned) Space 20

21 Ch Dec Hex Description GSM 3.38 ˆ (unassigned) Space (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 (unassigned) Space (unassigned) Space (unassigned) Space (unassigned) Space (unassigned) Space (unassigned) Space (unassigned) Space (unassigned) Space (unassigned) Space (unassigned) Space š 154 9a (unassigned) Space 155 9b (unassigned) Space œ 156 9c (unassigned) Space 21

22 Ch Dec Hex Description GSM d (unassigned) Space ž 158 9e (unassigned) z Ÿ 159 9f (unassigned) Y 160 a0 Hard space Space 161 a1 Inverted Exclamation Point No change 162 a2 Cent c 163 a3 Pound/Sterling No change 164 a4 General Currency Symbol No change 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 Ordinal Space «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

23 Ch Dec Hex Description GSM 3.38 ³ 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 Ordinal» 187 bb Right Double Guillemet Space " ¼ 188 bc 1/4 Space ½ 189 bd 1/2 Space ¾ 190 be 3/4 Space 191 bf Inverted Question Mark No change À 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

24 Ch Dec Hex Description GSM 3.38 È 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

25 Ch Dec Hex Description GSM 3.38 Ý 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

26 Ch Dec Hex Description GSM 3.38 ò 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

27 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 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: 024A3A51D195CDD008001B 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 ) The first character T The second character E The third character S The fourth character T <song sequence length> 2 song patterns 000 <pattern header> Pattern header id 00 <pattern id> A-part 0000 <loop value> no loop <pattern specifier> <length of the new pattern> 13 pattern instructions 100 <tempo instruction id> 27

28 Bit string Description Value <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> <command end> RTTL If the RTTL format is being used as the source format. The file will need to be converted to the MIDI format 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 Mail Transfer Format Before sending the OTA file through SMTP, it has to be converted to ASCII-coded hexadecimal format Ports For this application, both the originating port and destination port values are 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

29 7.2.1 Format Coding The NLM format looks like the following: 4E4C4D E C E FFFC E F 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: 02F E C E FFFC E F Ports For this application, both the originating port and destination port values are The length value is always Payload Explanation The NLM format looks like this: 4E4C4D E C E FFFC E F 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 first byte ("00") is the info-field of the smart messaging. 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. The fourth byte is the depth of the bitmap (the number of gray scales). 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: 00480E C E FFFC

30 E F Ports For this application, both the originating port and destination port values are The length value is always 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 Picture Coding An example of payload format is: 00481C E FF BFF FFFC FF3C FF FFF FFFC F7FFC C7FFC FF C6 39E53924E AA AA45157D54F E53888F C000 Inside this PDU, the first 4 bytes (the blue text above) provide 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 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. The fourth byte is the depth of the bitmap (the number of gray scales). 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: C E FF BFF FFFC FF3C FF FF F C C639E53924E AA AA45157D54F E53888F C 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 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: C E FF BFF FFFC FF3C FF

31 C C639E53924E AA AA45157D54F E53888F C000 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 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: 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 00E 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: T DTEND: T AALARM: T084500;;; END:VEVENT END:VCALENDAR This message must be translated in hexadecimal ASCII format and forms the PDU to be sent. 31

32 For this application, both the originating port and destination port values are 00E 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

33 8 APPENDIX D: ERROR MESSAGES RETURNED DURING MESSAGE SENDING Value Message Text What to do? Server currently unavailable to process your message, please try later Server currently unavailable to process your message, please try later Server currently unavailable to process your message, please try later Server currently unavailable to process your message, please try later Server currently unavailable to process your message, please try later Server currently unavailable to process your message, please try later. send an to send an to send an to send an to send an to send an to 600F 600F Authentication failure send an to Bad format for field DCS in section SETUP. check syntax of DCS field Bad format for field PID in section SETUP. check syntax of PID field Bad format for field MobileNotify in section SETUP. check syntax of MobileNotify field Bad format for field MailAckType in section SETUP. check syntax of MailAckType field Bad format or missing mandatory value for field Text in section MESSAGE Bad format or missing mandatory value for field List in section MSISDN. Text or Binary field must be fulfilled List field must be fulfilled 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 Bad format for field ValidityPeriod in section SETUP. check syntax of ValidityPeriod field Bad format or missing mandatory value for field DestinationPort in section SETUP. DestinationPort= empty field 33

34 Value Message Text What to do? Bad format or missing mandatory value for field Length in section MESSAGE Bad format or missing mandatory value for field Binary in section MESSAGE. must have Length when Binary field binary message must be 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 length. compare the length of binary field and Length= Error when processing the message. send an to service.desk@sybase.com Error when processing the message. check message syntax Server currently unavailable to process your message please try later. send an to service.desk@sybase.com 34

35 9 REFERENCES [1] GSM TS 03.38: Digital cellular telecommunications system (Phase 2+); Alphabets and language-specific information (GSM 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 version 5.7.1) [3] Smart Messaging Specification, Revision Nokia Mobile Phones Ltd [4] Graphic Message Service Syntax, Revision Nokia Mobile Phones Ltd Nokia FAQ: 35

36 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 for additional trademark information and notices.