Re: Operator Logo weirdness

2001-11-01 Thread Andreas Fink

Hey Guys, I'm trying to send an operator logo to a 3390 handset, and Im
having some weirdness. i can send data, but when I hit save, it doesnt
actually replace my logo (I read thats because the MCC/MNC dont match the
ones used on my phone currently) I've determined that FIDO (my carrier) uses
302-37 as the MCC/MNC. I converted these to HEX and came up with 12E 25 (So,
I put in %12%0E%25 into my URL). Still no luck. Can anyone explain? I've
been pulling my hair out reading hte nokia specs all day. thanks



The operatorcode is constructed:
   %30 %ab %cd %ef %0A

where %ab %cd %ef are operator specific. They are constructed out of 
the mobile network code and the mobile coutry code and are in 
reversed BCD format.

Meaning for a MCC = 234 and MNC = 10 (BT Cellnet)
  you will get %32%F4%01

so your 302-37 becomes  %03%F2%73.

I've attached a document I once wrote for encoding. Gives a few hints...

-- 

Andreas Fink
Fink-Consulting

--
Tel: +41-61-6932730 Fax: +41-61-6932729  Mobile: +41-79-2457333
Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland
E-Mail:  [EMAIL PROTECTED]  Homepage: http://www.finkconsulting.com
--
Something urgent? Try http://www.smsrelay.com/  Nickname afink



Here's some examples for you.

--HEADER---

To send binary messages you have to set udh to the following value


ud=%06%05%04%a1%a2%b1%b2

a1/a2 are the sender port
b1/b2 are the receiver port (usually zero)


%06 says that the total UDH header is 6 bytes
%05 says its a information element of WAP Port
%04 says that this information element is 4 bytes long
%a1%a2 are the two bytes specifying the destination port
%b1%b2 are the two bytes specifying the source port

Example:
   VCALENDAR
udh=%06%05%04%23%F5%00%00
   PICTURE + TEXT (Multipart)
 udh=%06%05%04%15%8A%00%00
   OPERATOR LOGO
 udh=%06%05%04%15%82%00%00
   RINGTONE
 udh=%06%05%04%15%81%00%00


--CONTENT---

The content is the content of the text= value and can be binary and 
contain zero's. So it is as usual URL encoded.

Pictures (in general) are constructed using the OTA spec.
OTA means:

byte 0: Version  flags. Usually %00
byte 1: width of the image
byte 2: height of the image
byte 3: bithdepth of the image. %01 for black and white.
byte 4: and following are the pixels of the image.

Then whats following is the image as a BITALIGNED structure.
If you are familiar with LogoManager (www.logomanager.co.uk), they 
are writing the image file (NLM) the same way but with 6 bytes in 
addition in the header and the image being BYTE aligned. I use the 
NLM format for storing the image so I have a C routine which changes 
from byte-aligned to bitaligned. This does only apply for large 
pictures as the small ones are falling on a bit/byte boundary. If you 
need that, let me know. It's a plain C routine.

The operatorcode is constructed:
   %30 %ab %cd %ef %0A

where %ab %cd %ef are operator specific. They are constructed out of 
the mobile network code and the mobile coutry code and are in 
reversed BCD format.

Meaning for a MCC = 234 and MNC = 10 (BT Cellnet)
  you will get %32%F4%01

Ringtones you apparently have the spec. I've never created ringtones. 
I simply send whats in the file and use LogoManager's converter to 
create OTT files which are the binary representation of the ringtones.

Pictures with text (Multipart message)

This is

%30   version
%00   text part
%length of text (high byte)
%length of text (low byte)

bytes of text...

%02  picture part
%length of picture (high byte)
%length of picture (low byte)

...bytes of picture...


etc. etc.



Now to the splitting of SMS. On our system you dont have to split the 
data. The system does automatically split the data into chunks and 
modifies the user data header on the fly.
If you dont leave the splitting of SMS to us you have to expand the 
UDH header by adding another information element, the concatenation 
element.


generally a UDH header is built out of:

byte 1: length of total UDH header
byte 2: information element type
byte 3: length of this information element
byte 4...n  the information of that element
byte n+1: next information element type
byte n+2: next information element size..
  etc etc.

information element types:
type=%05 means its a WAP port information
type=%00 means its a concatenation information

there are others I never used.

WAP Port information (type %05)

Example:
%06 %05 %04 %23%F5 %00%00

%06 means there are 6 bytes total in this UDH (not including this byte)
%05 means this is a WAP port information
%04 means there are 4 bytes following
%23%F5 is the destination port
%00%00 is the source port


concatenation example:
%06 means there are 5 bytes total in this UDH (not including this byte)
%00 means it is a concatenation info
%03 means there is 3 bytes in 

Re: GSM modem

2001-11-01 Thread David Holland

On Wed, Oct 31, 2001 at 08:26:47PM +0100, Fernando Primo wrote:
 Finaly I bought the GSM modem and I have got to send/recive menssage, but
 now I have a little problem, and I don´t  know if you will be able to solve
 it. When I send special character, like ñ, ú, ó, á, é, í, ü , I don´t get
 to recive them correctly. Is a configuration problem of GSM modem? or  Is a
 kannel problem?
 I have seen a file alt_charsets.h in source files, but I don´t know if i
 have to modify this file to solve this problem and how to do it. ???

Sorry, no idea. (I am not a programmer, etc.) I've cc'ed the devel
list; someone there should know.

Dave
-- 
David Holland   =*=   Systems Manager   =*=   tel: +44 01223 478900
http://www.3glab.com/   =*= 3G Lab, UK  =*=   fax: +44 01223 478901




RE: Strange kannel behaviour

2001-11-01 Thread Paul Keogh


 Our Kannel WAP gateway is exhibiting some strange behaviour 
 when visiting
 a few sites.  (Notably wap.ft.com).
 
 The request gets sent off fine, and Kannel sees an HTTP 302 status
 message, however it never seems to get the headers or the 
 Location header
 and eventually the WAP device just times out.

I've looked specifically at wap.ft.com.

The problem is that the HTTP headers coming back with the 302 indicate
a content length of 10, but there's no body available for reading.
Kannel does'nt treay this as a valid transaction and just returns,
with no indication of an error.

I'll have to put in some HTTP header dumps to confirm the debugger
analysis, but that's what it looks like to me.