Thanks Nisan,

BTW, you patch (TLV, receipted_message_id, message_state) works well for me. Do you know if this patch will go to official CVS tree?

Nisan Bloch wrote:

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








--
David Chkhartishvili
Tel: 995 99 182418





Reply via email to