Hi list. Since we're already discussing the at2 gsm7bit escaping issue, I would like to resubmit my suggested fix for the problem (as apparently it did not arrive to the proper authorities the first time). my apologies if you are reading it for the second time. I would like to hear any comments on the patch, especially if it is rejected.
TIA
Oded Arbel
m-Wise Inc.
[EMAIL PROTECTED]
--
Joe: "Billy prefers models and limousines. I can do with hookers and
taxis."
-- from "Hard Core Logo"
-----Original Message-----
From: Alex Judd [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 24, 2002 1:56 PM
To: Oded Arbel
Subject: RE: [PATCH] smsc_at2.c not counting escape caracters (gsm7bit)
Looks sensible. Check your at2_wait_mdoem_command which you're calling
with 4 parameters in the patch however I think adding your changes to
cvs
makes sense.
Alex
On Thu, 24 Jan 2002, Oded Arbel wrote:
> my first patch (as is Lucio Ferrao's) is to
> encode to gsm before the length calculation.
>
> Attached is my email containing the second patch.
--- Begin Message ---
Hi list.
sorry about that last post - thinking about it, it doesn't seem to me
like the right solution : yea, it works, but it doesn't address the
wider issue which Andreas Fink mentioned.
So, for your inspection, I submit this larger patch, which I hope solves
the particular problem Andreas Fink talked about, and as a side effect,
helps me with a cleaner solution to the problem with AT2. this patch is
against current CVS, and it's a bit large - so I'll try to explain :
to sms.c/.h I added a function called sms_msgdata_len() to which you can
pass a Msg struct and get the number of actual septets or octets this
message will contain after encoding (based on the message's coding).
I then changed smsc_at2.c to use that function to intialize len in
at2_pdu_encode() to the right value, no matter what encoding the msg
will be delivered.
then to the real problem at hand : to shared.c I added the function
extract_msgdata_part_by_coding() which is a wapper for
extract_msgdata_part() that will make sure that if the message is 7 bit
coded and contains 'escaped' characters, it will cut the message to the
right size. I then proceeded to change sms_split() to use the two new
functions.
I hope this will help, and have a nice day :-)
Oded Arbel
m-Wise Inc.
[EMAIL PROTECTED]
--
Trifles make perfection, and perfection is no trifle.
-- Michelangelo
-----Original Message-----
From: Oded Arbel
Sent: Tuesday, January 15, 2002 12:29 PM
To: Andreas Fink
Cc: [EMAIL PROTECTED]
Subject: RE: A question about PDU encoding in smsc_at2
Thank you all for the responses..
I couldn't find where messages get split in smsc_at2 , from my tests it
appears that messages get truncated and not split - but I can't figure
out where that happens. anyway - this small patch will convert to gsm 7
bit alphabet early, before the length computations, and does solve the
escape sequences problem for me.
the usual warnings - "Works For Me"(tm), YMMV, etc'.
Oded Arbel
m-Wise Inc.
[EMAIL PROTECTED]
--
"Some say life is hell and death an escape, others say heaven awaits us
in the world beyond, but either way I need a new pair of shoes."
-- Privateer.
-----Original Message-----
From: Andreas Fink [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 14, 2002 6:38 PM
To: Oded Arbel
Cc: [EMAIL PROTECTED]
Subject: RE: A question about PDU encoding in smsc_at2
>This is not exactly what I had in mind - (a) as this kind of string
>would get translated by kannel to '?<' as ESC will be translated
>directly to '?'. (b) the GSM standards _currently_ do define the ESC
>sequences as valid. I'm not really worried about current standard
>support in phone (as newer phones would surely conform to the current
>standards), but more with standard support within Kannel. and my
>question is (again) - which do you think is the correct implementation,
>Kannel's counting only actual characters, or Siemens M20's counting
>every septet ?
>
>P.S
>tests show that some phones just silently ignore the escape sequences
>(showing the character after the ESC - the triangle bracket), for
>example - the Nokia 33, and some show the intended result - the square
>bracket, for example - the Nokia 71.
>
>Oded Arbel
>m-Wise Inc.
>[EMAIL PROTECTED]
>
What I can tell from EMI usage, the escape sequence stuff is slightly
broken.
I got customers sending \n in their text (because they've forgotton
to replace it with linefeed). In kannel this translates the \ to two
characters. The problem here is that it increses the size of the text
and this AFTER the message has been split. The result of that is that
we will end up with SMS being longer than 160 characters.
So while you take a look into this, think about this fact.
The final header has to be the number of octets of the SMS after
escape sequences have been applied. The escape stuff is something
done in the phone and the SMSC never cares about it. For the SMSC its
just a stream of bytes.
--
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
--- End Message ---
gw.patch
Description: gw.patch
