Re: mo-recode for SMPP (possibly not working)

At 12:34 PM 4/4/03 +0500, David Chkhartishvili wrote:
>Nope,
>
>I'm getting message:
>
>INFO: NOTE: sender and receiver same number <520>, ignoring!


mm.. this is a bug we found the other day.. i cannot get to the code now, 
will pull patch later.

nisan




>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
>
>
>