Re: mo-recode for SMPP (possibly not working)
David Chkhartishvili <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Organization | MagtiCom Ltd. |
| Message-ID | <[email protected]> |
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 >>>> <@9@9@1@8@2@4@1@8@*@t@ >>>> @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