**>From: "Andrew Wat @ ASTRI" <[EMAIL PROTECTED]>
**>To: <[EMAIL PROTECTED]>
**>Subject: Re: OTA info
**>Date: Fri, 15 Aug 2003 10:04:01 +0800
**>
**>Hi there,
**>
**>Since I used HTTP POST to Kannel for sending the SMS, the followings headers
**>are needed:
**>
**>X-Kannel-PID: 7F
**>X-Kannel-Alt-DCS: 1
**>X-Kannel-MClass: 3
**>X-Kannel-Coding: 2
**>
**>This combination get the right TP-PID and TP-DCS which should be 7F and F6
**>as required by the GemPlus OTA.
**>
**>Thanks
**>Andrew
**>
**>> ----- Original Message -----
**>> From: "Oscar Flores" <[EMAIL PROTECTED]>
**>> To: "'Andrew Wat @ ASTRI'" <[EMAIL PROTECTED]>
**>> Sent: Thursday, August 14, 2003 9:16 PM
**>> Subject: RE: OTA info
**>>
**>>
**>> > Hi Andrew,
**>> >
**>> > I'm working with Cidar in this project and would you mind sending us
**>> > some examples of how you implement this on Kannel? We will apreciate
**>> > this a lot.
To add some more info to the cause:
The Kannel version was 1.3.1 (not the current cvs which changed the
interpretation of some of the variables like Coding and MClass).
GemPlus' ADE Parser can generate an ASCII hex dump of the OTA message
which should be sent to the SIM. This OTA message may or may not
fit into one single SMS message. If it does not fit, then
the ADE Parser will split up the OTA message to fit into multiple
140 Octet SMS messages. The hex dump will contain all the SMS's
concatenated into one hex dump. You are responsible for splitting
up the hex dump before sending it to Kannel (otherwise, Kannel
will try to split it up for you and screwup the segmentation of the
OTA).
You need to preprocess the OTA hex dump before sending it to Kannel.
1) Convert the hex dump back to binary. You will send the
binary to kannel as an octet-stream.
2) Read the first octet of the binary. This octet represents the
length of the data for an SMS message. Each SMS message inside the
OTA will be prefixed with the its length. If it is 8C (140 decimal)
and there are still more octets after the 140th octet then that
means more SMS's will need to be sent.
3) Read however many octets as designated by the length octet.
4) Discard the length octet. It should not be sent to Kannel.
5) Make an HTTP_POST connection to Kannel's sendsms-user service.
6) Generate the HTTP_POST with the added headers stated by Andrew
7) Indicate the content-type will be application/octet-stream
8) Dump the binary data to kannel
9) If there were more octets after the first SMS, then go back to
Step 2 and repeat until no more octets are left from the OTA.
The HTTP_POST should look something like:
POST /cgi-bin/sendsms HTTP/1.0
X-Kannel-Username: username_from_sendsms-user
X-Kannel-Password: password_from_sendsms-user
X-Kannel-From: +MY_MSISDN_NUMBER
X-Kannel-To: +SIMS_MSISDN_NUMBER
X-Kannel-PID: 127
X-Kannel-Alt-DCS: 1
X-Kannel-MClass: 3
X-Kannel-Coding: 2
Content-Type: application/octet-stream
Content-Length: 140
[Beginning of the binary data from the OTA]
If there are more than one SMS within the hex dump, then you will need
to send more SMS's.
Regards,
Davy Chan
