Re: mo-recode for SMPP (possibly not working)
On Friday 04 April 2003 11:56, Stipe Tolj wrote: Alexander Malysh wrote: Hi Stipe, All, On Friday 04 April 2003 11:32, Stipe Tolj wrote: Nope, I'm getting message: INFO: NOTE: sender and receiver same number 520, ignoring! it's comming from smsbox... and this is a bug (imho). Andreas ask me the same, here is what I wrote him: if you consider an ME (message entity) and a message to be a flow of information from two *independent* MEs, then it's illogical. ;) A message is a lingual/physical mechanism to transmit information. If the MEs are teh same (receiver=sender), then you don't have to transmit. ;) you are right here ;) but ... If I want to send such sms , then kannel must support them! It's a user decision to send such message... Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are -- Best Regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: http://www.centrium.de msn: [EMAIL PROTECTED] smime.p7s Description: signature
Re: mo-recode for SMPP (possibly not working)
Citando Stipe Tolj [EMAIL PROTECTED]: PS: This reminds me that we could mo-recode it to utf-8 instead of iso, with a parameter ;) Kannels internal charset is ISO (latin1). mo-recode-charset = utf-8 ? ;) it's a simple patch. Just carry this string to mo-recode function and give it to iconv. I guess it's always possible to convert from iso to utf8 and from ucs2 to utf8, thus you'll have always utf-8 requests. Besides, it's easier to do utf8-iso-utf8 than ucs2-something in external apps ;) -- br/ 11:19:11 up 132 days, 11:32, 2 users, load average: 0.22, 0.24, 0.32 A hacker does for love what others would not do for money.
Re: mo-recode for SMPP (possibly not working)
On Freitag, April 4, 2003, at 11:56 Uhr, Stipe Tolj wrote: Alexander Malysh wrote: Hi Stipe, All, On Friday 04 April 2003 11:32, Stipe Tolj wrote: Nope, I'm getting message: INFO: NOTE: sender and receiver same number 520>, ignoring! it's comming from smsbox... and this is a bug (imho). Andreas ask me the same, here is what I wrote him: if you consider an ME (message entity) and a message to be a flow of information from two *independent* MEs, then it's illogical. ;) A message is a lingual/physical mechanism to transmit information. If the MEs are teh same (receiver=sender), then you don't have to transmit. ;) if I'm sending one message to a mobile and I want to have it display the originator to be the mobile's number, thats what it should be Andreas Fink Global Networks Switzerland AG -- Tel: +41-61-333 Fax: +41-61-334 Mobile: +41-79-2457333 Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- Send SMS to +979 979 UNICEF (+979979864233) to donate a small amount to the children of Iraq. http://www.gni.ch/unicef
Re: mo-recode for SMPP (possibly not working)
Citando David Chkhartishvili [EMAIL PROTECTED]: Here is smsbox log. original message I've sent was: 99182418*t t t t and curillic letter on the end. You can see that '@' sign was added before all characters. 2003-03-28 18:16:02 [4] INFO: Starting to service @[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ @t@ @t@ @t@ è from 99599182418 to 5244 2003-03-28 18:16:02 [9] DEBUG: data: 50 4f 53 54 20 2f 72 65 POST /re 2003-03-28 18:16:02 [9] DEBUG: data: 70 6c 79 5f 43 4c 49 52 ply_CLIR 2003-03-28 18:16:02 [9] DEBUG: data: 2e 70 68 70 3f 73 65 6e .php?sen 2003-03-28 18:16:02 [9] DEBUG: data: 64 65 72 3d 39 39 35 39 der=9959 2003-03-28 18:16:02 [9] DEBUG: data: 39 31 38 32 34 31 38 26 9182418 2003-03-28 18:16:02 [9] DEBUG: data: 74 65 78 74 3d 25 34 30 text=%40 2003-03-28 18:16:02 [9] DEBUG: data: 39 25 34 30 39 25 34 30 9%409%40 2003-03-28 18:16:02 [9] DEBUG: data: 31 25 34 30 38 25 34 30 1%408%40 2003-03-28 18:16:02 [9] DEBUG: data: 32 25 34 30 34 25 34 30 2%404%40 2003-03-28 18:16:02 [9] DEBUG: data: 31 25 34 30 38 25 34 30 1%408%40 2003-03-28 18:16:02 [9] DEBUG: data: 2a 25 34 30 74 25 34 30 *%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 34 30 74 25 34 30 +%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 34 30 74 25 34 30 +%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 34 30 74 25 34 30 +%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 45 38 25 33 43 20 +%E8%3C 2003-03-28 18:16:02 [9] DEBUG: data: 48 54 54 50 2f 31 2e 31 HTTP/1.1 There's two errors in this. First, something is decoding ucs2 (double bytes) chars from gsm alphabet, which is wrong. ucs2 should be treated just like 8 bits and passed through without conversion. You should get a %009 (is %00 + '9') %00+ (is %00 + encoded space) %E8%3C Could someone test if this smsc module, in cvs, still have this behaviour ? Can you, David, use a newer version and see if you get the %00 insted of %40 ? Second, mo-recode will only recode to iso IF it can do it. You have a %E8%3C cyrilic char, which probably won't be possible to convert to iso. As soon as you have a working version that sends %00, you'll probably have to, in you php, analise content-type header (charset=utf-16be) and convert it yourself to utf-8 or try to convert to iso and ignore non-converted chars. PS: This reminds me that we could mo-recode it to utf-8 instead of iso, with a parameter ;) -- br/ 00:47:56 up 132 days, 1:01, 2 users, load average: 0.41, 0.79, 0.92 [It is] best to confuse only one issue at a time. -- KR
Re: mo-recode for SMPP (possibly not working)
Hi At 11:09 AM 4/4/03 +0500, David Chkhartishvili wrote: Hi Bruno, I didn't followed to cvs tree for a bit, and I was suprised that my mo doesn't come to smsbox (same config works well with older versions). Do you get a message No sender/reciever in your smsbox logs? Nisan I've read cvs documantation, and I didn't find any big changes in sms-service group. Did I miss something, which isn't in documentation yet? Thanks Bruno David Rodrigues wrote: Citando David Chkhartishvili [EMAIL PROTECTED]: Here is smsbox log. original message I've sent was: 99182418*t t t t and curillic letter on the end. You can see that '@' sign was added before all characters. 2003-03-28 18:16:02 [4] INFO: Starting to service @[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ @t@ @t@ @t@ è from 99599182418 to 5244 2003-03-28 18:16:02 [9] DEBUG: data: 50 4f 53 54 20 2f 72 65 POST /re 2003-03-28 18:16:02 [9] DEBUG: data: 70 6c 79 5f 43 4c 49 52 ply_CLIR 2003-03-28 18:16:02 [9] DEBUG: data: 2e 70 68 70 3f 73 65 6e .php?sen 2003-03-28 18:16:02 [9] DEBUG: data: 64 65 72 3d 39 39 35 39 der=9959 2003-03-28 18:16:02 [9] DEBUG: data: 39 31 38 32 34 31 38 26 9182418 2003-03-28 18:16:02 [9] DEBUG: data: 74 65 78 74 3d 25 34 30 text=%40 2003-03-28 18:16:02 [9] DEBUG: data: 39 25 34 30 39 25 34 30 9%409%40 2003-03-28 18:16:02 [9] DEBUG: data: 31 25 34 30 38 25 34 30 1%408%40 2003-03-28 18:16:02 [9] DEBUG: data: 32 25 34 30 34 25 34 30 2%404%40 2003-03-28 18:16:02 [9] DEBUG: data: 31 25 34 30 38 25 34 30 1%408%40 2003-03-28 18:16:02 [9] DEBUG: data: 2a 25 34 30 74 25 34 30 *%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 34 30 74 25 34 30 +%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 34 30 74 25 34 30 +%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 34 30 74 25 34 30 +%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 45 38 25 33 43 20 +%E8%3C 2003-03-28 18:16:02 [9] DEBUG: data: 48 54 54 50 2f 31 2e 31 HTTP/1.1 There's two errors in this. First, something is decoding ucs2 (double bytes) chars from gsm alphabet, which is wrong. ucs2 should be treated just like 8 bits and passed through without conversion. You should get a %009 (is %00 + '9') %00+ (is %00 + encoded space) %E8%3C Could someone test if this smsc module, in cvs, still have this behaviour ? Can you, David, use a newer version and see if you get the %00 insted of %40 ? Second, mo-recode will only recode to iso IF it can do it. You have a %E8%3C cyrilic char, which probably won't be possible to convert to iso. As soon as you have a working version that sends %00, you'll probably have to, in you php, analise content-type header (charset=utf-16be) and convert it yourself to utf-8 or try to convert to iso and ignore non-converted chars. PS: This reminds me that we could mo-recode it to utf-8 instead of iso, with a parameter ;) -- David Chkhartishvili Tel: 995 99 182418
Re: mo-recode for SMPP (possibly not working)
Nope, I'm getting message: INFO: NOTE: sender and receiver same number 520, ignoring! Nisan Bloch wrote: Hi At 11:09 AM 4/4/03 +0500, David Chkhartishvili wrote: Hi Bruno, I didn't followed to cvs tree for a bit, and I was suprised that my mo doesn't come to smsbox (same config works well with older versions). Do you get a message No sender/reciever in your smsbox logs? Nisan I've read cvs documantation, and I didn't find any big changes in sms-service group. Did I miss something, which isn't in documentation yet? Thanks Bruno David Rodrigues wrote: Citando David Chkhartishvili [EMAIL PROTECTED]: Here is smsbox log. original message I've sent was: 99182418*t t t t and curillic letter on the end. You can see that '@' sign was added before all characters. 2003-03-28 18:16:02 [4] INFO: Starting to service @[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ @t@ @t@ @t@ è from 99599182418 to 5244 2003-03-28 18:16:02 [9] DEBUG: data: 50 4f 53 54 20 2f 72 65 POST /re 2003-03-28 18:16:02 [9] DEBUG: data: 70 6c 79 5f 43 4c 49 52 ply_CLIR 2003-03-28 18:16:02 [9] DEBUG: data: 2e 70 68 70 3f 73 65 6e .php?sen 2003-03-28 18:16:02 [9] DEBUG: data: 64 65 72 3d 39 39 35 39 der=9959 2003-03-28 18:16:02 [9] DEBUG: data: 39 31 38 32 34 31 38 26 9182418 2003-03-28 18:16:02 [9] DEBUG: data: 74 65 78 74 3d 25 34 30 text=%40 2003-03-28 18:16:02 [9] DEBUG: data: 39 25 34 30 39 25 34 30 9%409%40 2003-03-28 18:16:02 [9] DEBUG: data: 31 25 34 30 38 25 34 30 1%408%40 2003-03-28 18:16:02 [9] DEBUG: data: 32 25 34 30 34 25 34 30 2%404%40 2003-03-28 18:16:02 [9] DEBUG: data: 31 25 34 30 38 25 34 30 1%408%40 2003-03-28 18:16:02 [9] DEBUG: data: 2a 25 34 30 74 25 34 30 *%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 34 30 74 25 34 30 +%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 34 30 74 25 34 30 +%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 34 30 74 25 34 30 +%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 45 38 25 33 43 20 +%E8%3C 2003-03-28 18:16:02 [9] DEBUG: data: 48 54 54 50 2f 31 2e 31 HTTP/1.1 There's two errors in this. First, something is decoding ucs2 (double bytes) chars from gsm alphabet, which is wrong. ucs2 should be treated just like 8 bits and passed through without conversion. You should get a %009 (is %00 + '9') %00+ (is %00 + encoded space) %E8%3C Could someone test if this smsc module, in cvs, still have this behaviour ? Can you, David, use a newer version and see if you get the %00 insted of %40 ? Second, mo-recode will only recode to iso IF it can do it. You have a %E8%3C cyrilic char, which probably won't be possible to convert to iso. As soon as you have a working version that sends %00, you'll probably have to, in you php, analise content-type header (charset=utf-16be) and convert it yourself to utf-8 or try to convert to iso and ignore non-converted chars. PS: This reminds me that we could mo-recode it to utf-8 instead of iso, with a parameter ;) -- David Chkhartishvili Tel: 995 99 182418 -- David Chkhartishvili Tel: 995 99 182418
RE: mo-recode for SMPP (possibly not working)
It seems to be a problem in the translation from GSM to latin1. 0x00 is '@' in GSM alphabet. so I think there's something with that. What version of kannel are you using? Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 -Mensaje original- De: David Chkhartishvili [mailto:[EMAIL PROTECTED] Enviado el: lunes 31 de marzo de 2003 10:38 Para: [EMAIL PROTECTED] CC: Angel Fradejas; [EMAIL PROTECTED] Asunto: Re: mo-recode for SMPP (possibly not working) Any ideas about that? David Chkhartishvili wrote: Here is smsbox log. original message I've sent was: 99182418*t t t t and curillic letter on the end. You can see that '@' sign was added before all characters. 2003-03-28 18:16:02 [4] INFO: Starting to service @[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ @t@ @t@ @t@ è from 99599182418 to 5244 2003-03-28 18:16:02 [9] DEBUG: HTTP: Reusing connection to `localhost:80' (fd=29). 2003-03-28 18:16:02 [9] DEBUG: HTTP: Sending request: 2003-03-28 18:16:02 [9] DEBUG: Octet string at 0x809a380: 2003-03-28 18:16:02 [9] DEBUG: len: 397 2003-03-28 18:16:02 [9] DEBUG: size: 398 2003-03-28 18:16:02 [9] DEBUG: immutable: 0 2003-03-28 18:16:02 [9] DEBUG: data: 50 4f 53 54 20 2f 72 65 POST /re 2003-03-28 18:16:02 [9] DEBUG: data: 70 6c 79 5f 43 4c 49 52 ply_CLIR 2003-03-28 18:16:02 [9] DEBUG: data: 2e 70 68 70 3f 73 65 6e .php?sen 2003-03-28 18:16:02 [9] DEBUG: data: 64 65 72 3d 39 39 35 39 der=9959 2003-03-28 18:16:02 [9] DEBUG: data: 39 31 38 32 34 31 38 26 9182418 2003-03-28 18:16:02 [9] DEBUG: data: 74 65 78 74 3d 25 34 30 text=%40 2003-03-28 18:16:02 [9] DEBUG: data: 39 25 34 30 39 25 34 30 9%409%40 2003-03-28 18:16:02 [9] DEBUG: data: 31 25 34 30 38 25 34 30 1%408%40 2003-03-28 18:16:02 [9] DEBUG: data: 32 25 34 30 34 25 34 30 2%404%40 2003-03-28 18:16:02 [9] DEBUG: data: 31 25 34 30 38 25 34 30 1%408%40 2003-03-28 18:16:02 [9] DEBUG: data: 2a 25 34 30 74 25 34 30 *%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 34 30 74 25 34 30 +%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 34 30 74 25 34 30 +%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 34 30 74 25 34 30 +%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 45 38 25 33 43 20 +%E8%3C 2003-03-28 18:16:02 [9] DEBUG: data: 48 54 54 50 2f 31 2e 31 HTTP/1.1 2003-03-28 18:16:02 [9] DEBUG: data: 0d 0a 48 6f 73 74 3a 20 ..Host: 2003-03-28 18:16:02 [9] DEBUG: data: 6c 6f 63 61 6c 68 6f 73 localhos 2003-03-28 18:16:02 [9] DEBUG: data: 74 0d 0a 55 73 65 72 2d t..User- 2003-03-28 18:16:02 [9] DEBUG: data: 41 67 65 6e 74 3a 20 4b Agent: K 2003-03-28 18:16:02 [9] DEBUG: data: 61 6e 6e 65 6c 2f 63 76 annel/cv 2003-03-28 18:16:02 [9] DEBUG: data: 73 2d 0d 0a 43 6f 6e 74 s-..Cont 2003-03-28 18:16:02 [9] DEBUG: data: 65 6e 74 2d 54 79 70 65 ent-Type 2003-03-28 18:16:02 [9] DEBUG: data: 3a 20 74 65 78 74 2f 70 : text/p 2003-03-28 18:16:02 [9] DEBUG: data: 6c 61 69 6e 3b 20 63 68 lain; ch 2003-03-28 18:16:02 [9] DEBUG: data: 61 72 73 65 74 3d 55 54 arset=UT 2003-03-28 18:16:02 [9] DEBUG: data: 46 2d 31 36 42 45 0d 0a F-16BE.. 2003-03-28 18:16:02 [9] DEBUG: data: 58 2d 4b 61 6e 6e 65 6c X-Kannel 2003-03-28 18:16:02 [9] DEBUG: data: 2d 54 6f 3a 20 35 32 34 -To: 524 2003-03-28 18:16:02 [9] DEBUG: data: 30 0d 0a 58 2d 4b 61 6e 0..X-Kan 2003-03-28 18:16:02 [9] DEBUG: data: 6e 65 6c 2d 54 69 6d 65 nel-Time 2003-03-28 18:16:02 [9] DEBUG: data: 3a 20 32 30 30 33 2d 30 : 2003-0 2003-03-28 18:16:02 [9] DEBUG: data: 33 2d 32 38 20 31 34 3a 3-28 14: 2003-03-28 18:16:02 [9] DEBUG: data: 31 36 3a 30 32 0d 0a 58 16:02..X 2003-03-28 18:16:02 [9] DEBUG: data: 2d 4b 61 6e 6e 65 6c 2d -Kannel- 2003-03-28 18:16:02 [9] DEBUG: data: 53 4d 53 43 3a 20 74 65 SMSC: te 2003-03-28 18:16:02 [9] DEBUG: data: 73 74 0d 0a 58 2d 4b 61 st..X-Ka 2003-03-28 18:16:02 [9] DEBUG: data: 6e 6e 65 6c 2d 43 6f 64 nnel-Cod 2003-03-28 18:16:02 [9] DEBUG: data: 69 6e 67 3a 20 33 0d 0a ing: 3.. 2003-03-28 18:16:02 [9] DEBUG: data: 58 2d 4b 61 6e 6e 65 6c X-Kannel 2003-03-28 18:16:02 [9] DEBUG: data: 2d 53 65 72 76 69 63 65 -Service 2003-03-28 18:16:02 [9] DEBUG: data: 3a 20 64 65 66 61 75 6c : defaul 2003-03-28 18:16:02 [9] DEBUG: data: 74 0d 0a 43 6f 6e 74 65 t..Conte 2003-03-28 18:16:02 [9] DEBUG: data: 6e 74 2d 4c 65 6e 67 74 nt-Lengt 2003-03-28 18:16:02 [9] DEBUG: data: 68 3a 20 33 36 0d 0a 0d h: 36... 2003-03-28 18:16:02 [9] DEBUG: data: 0a 40 39 40 39 40 31 40 [EMAIL PROTECTED]@[EMAIL PROTECTED]@ 2003-03-28 18:16:02 [9] DEBUG: data: 38 40 32 40 34 40 31 40 [EMAIL PROTECTED]@[EMAIL PROTECTED]@ 2003-03-28 18:16:02 [9] DEBUG: data: 38 40 2a 40 74 40 20 40 [EMAIL PROTECTED]@t@ @ 2003-03-28 18:16:02 [9] DEBUG: data: 74 40 20
Re: mo-recode for SMPP (possibly not working)
David Chkhartishvili wrote: Any ideas about that? @[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ @t@ @t@ @t@ è from 99599182418 to 5244 That looks like an MO that the client has sent as Unicode to me. Can you check the dcs? -- Ian Cass
Re: mo-recode for SMPP (possibly not working)
David Chkhartishvili wrote: data coding is 8 (and that's correct). Well there you go then. data_coding 8 = UCS2. The guy has sent his MO with his handset set to Unicode. You need to parse 2 bytes at a time. -- Ian Cass
Re: mo-recode for SMPP (possibly not working)
I see, but I supposed that mo-recode will do that. Ian Cass wrote: David Chkhartishvili wrote: data coding is 8 (and that's correct). Well there you go then. data_coding 8 = UCS2. The guy has sent his MO with his handset set to Unicode. You need to parse 2 bytes at a time. -- Ian Cass -- David Chkhartishvili Tel: 995 99 182418
RE: mo-recode for SMPP (possibly not working)
Can anybody confirm that mo-recode feature of smsbox working properly? I'm using it, and works for me (TM) :-) Maybe you should heck if your provider sends you the proper DCS in the MO for Unicode messages. Angel Fradejas Mediafusion Espana, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08
Re: mo-recode for SMPP (possibly not working)
Nice to hear. I have set mo-recode in smsbox configuration to true (Is it enough??). Here is pdu dump of deliver_sm with cyrillic characters:2003-03-28 16:58:42 [5] DEBUG: type_name: deliver_sm 2003-03-28 16:58:42 [5] DEBUG: command_id: 5 = 0x0005 2003-03-28 16:58:42 [5] DEBUG: command_status: 0 = 0x 2003-03-28 16:58:42 [5] DEBUG: sequence_number: 1 = 0x0001 2003-03-28 16:58:42 [5] DEBUG: service_type: NULL 2003-03-28 16:58:42 [5] DEBUG: source_addr_ton: 1 = 0x0001 2003-03-28 16:58:42 [5] DEBUG: source_addr_npi: 1 = 0x0001 2003-03-28 16:58:42 [5] DEBUG: source_addr: 995 2003-03-28 16:58:42 [5] DEBUG: dest_addr_ton: 0 = 0x 2003-03-28 16:58:42 [5] DEBUG: dest_addr_npi: 1 = 0x0001 2003-03-28 16:58:42 [5] DEBUG: destination_addr: 5202 2003-03-28 16:58:42 [5] DEBUG: esm_class: 0 = 0x 2003-03-28 16:58:42 [5] DEBUG: protocol_id: 0 = 0x 2003-03-28 16:58:42 [5] DEBUG: priority_flag: 0 = 0x 2003-03-28 16:58:42 [5] DEBUG: schedule_delivery_time: NULL 2003-03-28 16:58:42 [5] DEBUG: validity_period: NULL 2003-03-28 16:58:42 [5] DEBUG: registered_delivery: 0 = 0x 2003-03-28 16:58:42 [5] DEBUG: replace_if_present_flag: 0 = 0x 2003-03-28 16:58:42 [5] DEBUG: data_coding: 8 = 0x0008 2003-03-28 16:58:42 [5] DEBUG: sm_default_msg_id: 0 = 0x 2003-03-28 16:58:42 [5] DEBUG: sm_length: 6 = 0x0006 2003-03-28 16:58:42 [5] DEBUG: short_message: 2003-03-28 16:58:42 [5] DEBUG:Octet string at 0x815ed70: 2003-03-28 16:58:42 [5] DEBUG: len: 6 2003-03-28 16:58:42 [5] DEBUG: size: 7 2003-03-28 16:58:42 [5] DEBUG: immutable: 0 2003-03-28 16:58:42 [5] DEBUG: data: 04 1c 04 38 04 40 ...8.@ 2003-03-28 16:58:42 [5] DEBUG:Octet string dump ends. What's wrong with it? Angel Fradejas wrote: Can anybody confirm that mo-recode feature of smsbox working properly? I'm using it, and works for me (TM) :-) Maybe you should heck if your provider sends you the proper DCS in the MO for Unicode messages. Angel Fradejas Mediafusion Espana, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 -- David Chkhartishvili Tel: 995 99 182418
Re: mo-recode for SMPP (possibly not working)
Here is smsbox log. original message I've sent was: 99182418*t t t t and curillic letter on the end. You can see that '@' sign was added before all characters. 2003-03-28 18:16:02 [4] INFO: Starting to service @[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ @t@ @t@ @t@ è from 99599182418 to 5244 2003-03-28 18:16:02 [9] DEBUG: HTTP: Reusing connection to `localhost:80' (fd=29). 2003-03-28 18:16:02 [9] DEBUG: HTTP: Sending request: 2003-03-28 18:16:02 [9] DEBUG: Octet string at 0x809a380: 2003-03-28 18:16:02 [9] DEBUG: len: 397 2003-03-28 18:16:02 [9] DEBUG: size: 398 2003-03-28 18:16:02 [9] DEBUG: immutable: 0 2003-03-28 18:16:02 [9] DEBUG: data: 50 4f 53 54 20 2f 72 65 POST /re 2003-03-28 18:16:02 [9] DEBUG: data: 70 6c 79 5f 43 4c 49 52 ply_CLIR 2003-03-28 18:16:02 [9] DEBUG: data: 2e 70 68 70 3f 73 65 6e .php?sen 2003-03-28 18:16:02 [9] DEBUG: data: 64 65 72 3d 39 39 35 39 der=9959 2003-03-28 18:16:02 [9] DEBUG: data: 39 31 38 32 34 31 38 26 9182418 2003-03-28 18:16:02 [9] DEBUG: data: 74 65 78 74 3d 25 34 30 text=%40 2003-03-28 18:16:02 [9] DEBUG: data: 39 25 34 30 39 25 34 30 9%409%40 2003-03-28 18:16:02 [9] DEBUG: data: 31 25 34 30 38 25 34 30 1%408%40 2003-03-28 18:16:02 [9] DEBUG: data: 32 25 34 30 34 25 34 30 2%404%40 2003-03-28 18:16:02 [9] DEBUG: data: 31 25 34 30 38 25 34 30 1%408%40 2003-03-28 18:16:02 [9] DEBUG: data: 2a 25 34 30 74 25 34 30 *%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 34 30 74 25 34 30 +%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 34 30 74 25 34 30 +%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 34 30 74 25 34 30 +%40t%40 2003-03-28 18:16:02 [9] DEBUG: data: 2b 25 45 38 25 33 43 20 +%E8%3C 2003-03-28 18:16:02 [9] DEBUG: data: 48 54 54 50 2f 31 2e 31 HTTP/1.1 2003-03-28 18:16:02 [9] DEBUG: data: 0d 0a 48 6f 73 74 3a 20 ..Host: 2003-03-28 18:16:02 [9] DEBUG: data: 6c 6f 63 61 6c 68 6f 73 localhos 2003-03-28 18:16:02 [9] DEBUG: data: 74 0d 0a 55 73 65 72 2d t..User- 2003-03-28 18:16:02 [9] DEBUG: data: 41 67 65 6e 74 3a 20 4b Agent: K 2003-03-28 18:16:02 [9] DEBUG: data: 61 6e 6e 65 6c 2f 63 76 annel/cv 2003-03-28 18:16:02 [9] DEBUG: data: 73 2d 0d 0a 43 6f 6e 74 s-..Cont 2003-03-28 18:16:02 [9] DEBUG: data: 65 6e 74 2d 54 79 70 65 ent-Type 2003-03-28 18:16:02 [9] DEBUG: data: 3a 20 74 65 78 74 2f 70 : text/p 2003-03-28 18:16:02 [9] DEBUG: data: 6c 61 69 6e 3b 20 63 68 lain; ch 2003-03-28 18:16:02 [9] DEBUG: data: 61 72 73 65 74 3d 55 54 arset=UT 2003-03-28 18:16:02 [9] DEBUG: data: 46 2d 31 36 42 45 0d 0a F-16BE.. 2003-03-28 18:16:02 [9] DEBUG: data: 58 2d 4b 61 6e 6e 65 6c X-Kannel 2003-03-28 18:16:02 [9] DEBUG: data: 2d 54 6f 3a 20 35 32 34 -To: 524 2003-03-28 18:16:02 [9] DEBUG: data: 30 0d 0a 58 2d 4b 61 6e 0..X-Kan 2003-03-28 18:16:02 [9] DEBUG: data: 6e 65 6c 2d 54 69 6d 65 nel-Time 2003-03-28 18:16:02 [9] DEBUG: data: 3a 20 32 30 30 33 2d 30 : 2003-0 2003-03-28 18:16:02 [9] DEBUG: data: 33 2d 32 38 20 31 34 3a 3-28 14: 2003-03-28 18:16:02 [9] DEBUG: data: 31 36 3a 30 32 0d 0a 58 16:02..X 2003-03-28 18:16:02 [9] DEBUG: data: 2d 4b 61 6e 6e 65 6c 2d -Kannel- 2003-03-28 18:16:02 [9] DEBUG: data: 53 4d 53 43 3a 20 74 65 SMSC: te 2003-03-28 18:16:02 [9] DEBUG: data: 73 74 0d 0a 58 2d 4b 61 st..X-Ka 2003-03-28 18:16:02 [9] DEBUG: data: 6e 6e 65 6c 2d 43 6f 64 nnel-Cod 2003-03-28 18:16:02 [9] DEBUG: data: 69 6e 67 3a 20 33 0d 0a ing: 3.. 2003-03-28 18:16:02 [9] DEBUG: data: 58 2d 4b 61 6e 6e 65 6c X-Kannel 2003-03-28 18:16:02 [9] DEBUG: data: 2d 53 65 72 76 69 63 65 -Service 2003-03-28 18:16:02 [9] DEBUG: data: 3a 20 64 65 66 61 75 6c : defaul 2003-03-28 18:16:02 [9] DEBUG: data: 74 0d 0a 43 6f 6e 74 65 t..Conte 2003-03-28 18:16:02 [9] DEBUG: data: 6e 74 2d 4c 65 6e 67 74 nt-Lengt 2003-03-28 18:16:02 [9] DEBUG: data: 68 3a 20 33 36 0d 0a 0d h: 36... 2003-03-28 18:16:02 [9] DEBUG: data: 0a 40 39 40 39 40 31 40 [EMAIL PROTECTED]@[EMAIL PROTECTED]@ 2003-03-28 18:16:02 [9] DEBUG: data: 38 40 32 40 34 40 31 40 [EMAIL PROTECTED]@[EMAIL PROTECTED]@ 2003-03-28 18:16:02 [9] DEBUG: data: 38 40 2a 40 74 40 20 40 [EMAIL PROTECTED]@t@ @ 2003-03-28 18:16:02 [9] DEBUG: data: 74 40 20 40 74 40 20 40 t@ @t@ @ 2003-03-28 18:16:02 [9] DEBUG: data: 74 40 20 e8 3ct@ . 2003-03-28 18:16:02 [9] DEBUG: Octet string dump ends. Angel Fradejas wrote: Nothing wrong there, data_coding is set to 8 in bearerbox. Maybe you can provide the smsbox log to see what it's getting there. Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] nombre de David Chkhartishvili Enviado el: viernes 28 de marzo de 2003 14:04 Para: Angel Fradejas CC: [EMAIL PROTECTED] Asunto: Re: mo-recode for SMPP
