Investigation continues... So, the first test was related to a "long message" which went out fine using coding=0 The second test I've performed was to send out a OTA message with coding=0 but behavior is not the same
In this case, the message coming from kannel is resent on the URL and the behavior is like the one described before, the message gets broken somehow. Checking for message details, the OTA is sent as a Octet byte (8 bits, not 7) so the correct behavior should be using the generic 8 bit encoding at 8 bits (coding=1) but... surprise... this does work only on 1 box on 3. 1st box (not working): Kannel bearerbox version `1.4.1'. Build `Oct 6 2006 13:34:37', compiler `4.0.2 20051125 (Red Hat 4.0.2-8)'. System Linux, release 2.6.11-1.1369_FC4, version #1 Thu Jun 2 22:55:56 EDT 2005, machine i686. Hostname komosubi, IP 10.100.10.10. Libxml version 2.6.20. Using OpenSSL 0.9.7f 22 Mar 2005. Compiled with MySQL 4.1.20, using MySQL 4.1.20. Using native malloc. (kannel stable 1.4.1) 2nd box (not working): Kannel bearerbox version `cvs-20080424'. Build `May 24 2008 14:54:26', compiler `4.0.2 20051125 (Red Hat 4.0.2-8)'. System Linux, release 2.6.11-1.1369_FC4, version #1 Thu Jun 2 22:55:56 EDT 2005, machine i686. Hostname komosubi, IP 10.100.10.10. Libxml version 2.6.20. Using OpenSSL 0.9.7f 22 Mar 2005. Compiled with MySQL 4.1.20, using MySQL 4.1.20. Using native malloc. (today CVS) 3rd box: (working): Kannel bearerbox version `1.4.1'. Build `Oct 17 2006 02:55:06', compiler `4.1.2 20061007 (prerelease) (Debian 4.1.1-16)'. System Linux, release 2.6.8-2-386, version #1 Thu May 19 17:40:50 JST 2005, machine i686. Hostname localhost.localdomain, IP 127.0.0.1. Libxml version 2.6.26. Using OpenSSL 0.9.8c 05 Sep 2006. Compiled with MySQL 5.0.24a, using MySQL 5.0.32. Using native malloc. (kannel_1.4.1-1sarge.1_i386.deb) 2008/5/24 Julien Buratto <[EMAIL PROTECTED]>: > Following my previous message, I've made some tests based on the > documentation which states that the message coding, when submitting > with the udh is changed to 8bits, I've added the "coding=0" variable > to my http request to smsbox and it seems that the UDH is not > re-written. > > I will perform some more tests. > > Julien > > 2008/5/23 Julien Buratto <[EMAIL PROTECTED]>: >> Hello, >> I've performed a little test getting a kannel generated UDH message >> and re-submit it back to kannel and had a strange behavior. >> >> Via HTTP I've sent an sms to smsbox such as >> text=123456789-123456789-.... till the body was 170 chars (long >> message) >> >> On the bearerbox logs I've seen that the message is sent sending two >> concatenated messages. >> UDH is 05 00 03 03 02 01 (first chunk) and second UDH is 05 00 03 03 >> 02 02 (second chunk) and this is a very cool feature of kannel: if you >> send a long message, kannel will automatically chunk it in "n" little >> chunks and write the correct UDH for you. >> >> So, now that I learnt how to chunk messages, I've tryed to send those >> 2 chunks separately,one at time, so that Kannel does not need to do >> the chunking automatically. >> >> So, I've taken the two generated chunk-sms that I've read before from >> the logs and resubmitted to the msbox as udh=%05%00%03%03%02%01 & >> text=123456789-... (for the first 154 chars) and then sent out another >> sms with the second chunk... udh=%05%00%03%03%02%02 & text=<...the >> rest of the message> >> >> What I've noticed, this time, is that Kannel changes the UDH to 0a 00 >> 03 04 02 01 00 03 c9 02 01 while the text isn't changed at all. >> >> So the point is, why does Kannel change that ? How can I prevent this ? >> >> thanks >> -- >> Julien >> > > > > -- > Julien Buratto > -- Julien Buratto
