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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.