So, I came up to the end finally. The final note is: 1) if you send a concatenated message: - create your 7 bytes UDH - set your coding=0 - set the body with your 153 chars EXAMPLE1: Without using Kannel auto-splitting: sms1) coding=0&udh=%05%00%03%81%02%01&text=%31%32%33%34%35%36%37%38%39%2d%31%32%33%34%35%36%37%38%39%2d%31%32%33%34%35%36%37%38%39%2d%31%32%33%34%35%36%37%38%39%2d%31%32%33%34%35%36%37%38%39%2d%31%32%33%34%35%36%37%38%39%2d%31%32%33%34%35%36%37%38%39%2d%31%32%33%34%35%36%37%38%39%2d%31%32%33%34%35%36%37%38%39%2d%31%32%33%34%35%36%37%38%39%2d%31%32%33%34%35%36%37%38%39%2d%31%32%33%34%35%36%37%38%39%2d%31%32%33%34%35%36%37%38%39%2d%31%32%33%34%35%36%37%38%39%2d%39%38%37%36%35%34%33%32%31%2d%39%38%37 sms 2) coding=0&udh=%05%00%03%81%02%02&text=%36%35%34%33%32%31%2d%39%38%37%36%35%34%33%32%31%2d
EXAMPLE 2: Using Kannel auto-splitting: text=123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-987654321-987654321-987654321- Note: %31%32%33 is the urlencoded form for "1"+"2"+"3" which is the string 123 2) if you send a plain 160 chars message - don't set any udh not coding and allow kannel to manage the coding (so coding=0 will be used as default) text=123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789- 3) if you send a OTA message - create your n-bytes UDH - set the coding=1 (8-bits) - set your body (available are 140-n-bytes used in the UDH) EXAMPLE (POP3 configuration): If you want to use a OMA-CP configuration message: <?xml version="1.0"?> <!DOCTYPE wap-provisioningdoc PUBLIC "-//WAPFORUM//DTD PROV 1.0//EN" "http://www.wapforum.org/DTD/prov.dtd";> <!-- So, let's start the configuratio using OMA CP 1.1 specifications --> <wap-provisioningdoc version="1.1"> <characteristic type="APPLICATION"> <!-- The APPID rappresents a unique identifier to POP3 --> <parm name="APPID" value="110" /> <!-- This is an internal ID to internal reference --> <parm name="PROVIDER-ID" value="MyPOPMail" /> <!-- Here is the POP3 server details --> <characteristic type="APPADDR"> <parm name="ADDR" value="pop.example.com" /> <!-- Port number for POP3 is normally 110 --> <characteristic type="PORT"> <parm name="PORTNBR" value="110" /> </characteristic> <!-- Here are the username/password of your POP3 server --> </characteristic> <characteristic type="APPAUTH"> <!-- Julien.buratto is my email's username to access via POP3 --> <parm name="AAUTHNAME" value="julien.buratto" /> <parm name="AAUTHSECRET" value="Password" /> </characteristic> </characteristic> <!-- Now let's configure the SMTP to send emails --> <characteristic type="APPLICATION"> <!-- Same as per any .application. you want to configure, the unique ID for smtp is 25 --> <parm name="APPID" value="25" /> <!-- Same provider ID as per POP3 so both POP3 and SMTP will be bound together --> <parm name="PROVIDER-ID" value="MyPOPMail" /> <!-- Emails will be sent as --> <parm name="FROM" value="[EMAIL PROTECTED]" /> <!-- Here is the SMTP server address --> <characteristic type="APPADDR"> <parm name="ADDR" value="smtp.example.com" /> <!-- Here is the SMTP port --> <characteristic type="PORT"> <parm name="PORTNBR" value="25" /> </characteristic> </characteristic> <!-- Here are the username/password to access the SMTP server if authenticated --> <characteristic type="APPAUTH"> <parm name="AAUTHNAME" value="OutgoingName" /> <parm name="AAUTHSECRET" value="Password" /> </characteristic> </characteristic> <!-- That's all folks, no more things to configure --> </wap-provisioningdoc> This would result in 3 SMS sent: 1 SMS) &coding=1& udh=%0b%05%04%0b%84%0b%84%00%03%82%03%01& text=%01%06%2f%1f%2d%b6%91%81%92%45%34%44%44%43%30%46%30%34%35%39%42%44%31%35%32%42%37%31%41%32%33%35%38%43%34%32%46%38%34%36%46%38%42%33%38%45%44%34%41%00%03%0b%6a%00%c5%45%03%31%2e%31%00%01%c6%00%01%55%01%87%36%06%03%31%31%30%00%01%87%38%06%03%4d%79%50%4f%50%4d%61%69%6c%00%01%c6%56%01%87%34%06%03%70%6f%70%2e%65%78%61%6d%70%6c%65%2e%63%6f%6d%00%01%c6%00%00%53%01%87%23%06%03%31%31%30%00 2 SMS) coding=1& udh=%0b%05%04%0b%84%0b%84%00%03%82%03%02& text=%01%01%01%c6%00%01%57%01%87%31%06%03%6a%75%6c%69%65%6e%2e%62%75%72%61%74%74%6f%00%01%87%32%06%03%50%61%73%73%77%6f%72%64%00%01%01%01%c6%55%01%87%36%06%03%32%35%00%01%87%38%06%03%4d%79%50%4f%50%4d%61%69%6c%00%01%87%05%03%46%52%4f%4d%00%06%03%73%6f%6d%65%6f%6e%65%40%65%78%61%6d%70%6c%65%2e%63%6f%6d%00%01%c6%56%01%87%34%06%03%73%6d%74%70%2e%65%78%61%6d%70%6c%65%2e%63%6f%6d%00%01%c6%00 3 SMS) coding=1&udh=%0b%05%04%0b%84%0b%84%00%03%82%03%03&text=%00%53%01%87%23%06%03%32%35%00%01%01%01%c6%00%01%57%01%87%31%06%03%4f%75%74%67%6f%69%6e%67%4e%61%6d%65%00%01%87%32%06%03%50%61%73%73%77%6f%72%64%00%01%01%01%01 (more info on how to create the binary stuff here: http://dev.mobi/article/email-configuration-sms) Julien 2008/5/24 Julien Buratto <[EMAIL PROTECTED]>: > 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 > -- Julien Buratto
