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
gw.patch
Description: gw.patch