Re: [PATCH] Chararcter @ in SMPP

Andreas Fink <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <[email protected]>
On Mittwoch, Oktober 2, 2002, at 10:42  Uhr, Dedy Sutanto wrote:

> Thank’s for your vote Oded. =)
>
>  
>
> But if you suspect this problem as broken implementation of SMSC, I am 
> not agreed with you.
>
> I already test kannel 1.2.0 with 2 kinds of SMSC, Logica 2600 and 
> Comverse SMSC.
>
> Regarding this problem, kannel has problem both SMSC.
>
>  
>
> After patching charset.c, character @ work properly
>
>  

I have to disagree with you.
In GSM character set @ is coded as 0x00.
If your SMSC doesnt want to have @ encoded as 0x00 but wants to have 
ISO8859-1 as input, this is something which should be taken care of in 
the SMSC driver or on the SMSC itself. patching charset.c would make 
all SMSC drivers fail. 0x00 encoding is correct according to the 
standard GSM character set. If your SMSC wants some other character set 
as input, well then you should make a patch in smsc_smpp however its 
very new to me that SMPP specifies non GSM character set as default.

And frankly if Logica and Comverse do it different, this doesnt mean 
automatically they follow the SMPP specification.

So I vote -2 also for this patch.
IF this is really to be done, then we should have a config parameter 
for SMPP driver to tell which charset to send messages to the SMSC. Be 
aware if @ is broken, all the other accented characters are probably 
too.


> 2002-10-0215:16:25[4] INFO: Starting to service <test¡yahoo.com 
> kannel¡3glab.org> from <62818445010> to <9877>
>
>  
>
>  
>
> Debug Log from Logica SMSC:
>
>  
>
> [telepath@sms] tail -f bca_2271.dbg0
>
> [ -> 0   [+238.707325s] }
>
>  
>
> <unknown>:  command ID 21  [apiext.c,1586]
>
> <unknown>:  command Status 0  [apiext.c,1593]
>
> <unknown>:  Sequence No. 18  [apiext.c,1600]
>
> [   [+238.708048s] {
>
> > [:  SMPP Hex Dump (16 bytes) Sending to ESME  [apiext.c,1631]
>
> > [:  00 00 00 10 80 00 00 15 00 00 00 00 00 00 00 12   
> ->................<-  [apiext.c,1663]
>
> [ -> 0   [+238.708786s] }
>
>  
>
> [   [+260.350837s] {
>
> > [:  SMPP Hex Dump (84 bytes) Sending to ESME  [apiext.c,1631]
>
> > [:  00 00 00 54 00 00 00 05 00 00 00 00 00 00 00 03   
> ->...T............<-  [apiext.c,1663]
>
> > [:  4E 4F 52 45 50 00 01 01 36 32 38 31 38 34 34 35   
> ->NOREP...62818445<-  [apiext.c,1663]
>
> > [:  30 31 30 00 00 01 39 38 37 37 00 03 00 00 00 00   
> ->010...9877......<-  [apiext.c,1663]
>
> > [:  00 00 00 00 1F 74 65 73 74 40 79 61 68 6F 6F 2E   
> ->.....test@yahoo.<-  [apiext.c,1663]
>
> > [:  63 6F 6D 20 6B 61 6E 6E 65 6C 40 33 67 6C 61 62   ->com 
> kannel@3glab<-  [apiext.c,1663]
>
> > [:  2E 6F 72 67                                       
> ->.org            <-  [apiext.c,1663]
>
> [ -> 0   [+260.359819s] }
>
>  
>
> <unknown>:  command length 17  [apiext.c,1562]
>
> [   [+260.364647s] {
>
> > [:  SMPP Hex Dump (17 bytes) Received from ESME  [apiext.c,1631]
>
> > [:  00 00 00 11 80 00 00 05 00 00 00 00 00 00 00 03   
> ->................<-  [apiext.c,1663]
>
> > [:  00                                                
> ->.               <-  [apiext.c,1663]
>
> [ -> 0   [+260.365779s] }
>
>  
>
> <unknown>:  command ID -2147483643  [apiext.c,1586]
>
> <unknown>:  command Status 0  [apiext.c,1593]
>
> <unknown>:  Sequence No. 3  [apiext.c,1600]
>
> <unknown>:  Message ID :   [apiext.c,632]
>
> <unknown>:  command length 16  [apiext.c,1562]
>
>  
>
>  
>
> Regards
>
> -dedy-
>
>  
>
> -----Original Message-----
> From: Oded Arbel [mailto:[email protected]]
> Sent:Wednesday, October 02, 20022:32 PM
> To: Dedy Sutanto; [email protected]
> Subject: RE: [PATCH] Chararcter @ in SMPP
>
>  
>
> I'm sorry, but I have to vote -1 on this patch. I would have voted -2 
> if possible, because this patch breaks standard compatibility in 
> Kannel entirly (GSM 03.38) in order to support a small number of 
> broken SMSC.
>
>  
>
> there is a problem with @ mapping in some non-standard compliant 
> SMSCs, but I don't think that the solution is to break Kannel to match 
> - mostly as that would make Kannel non-standard compliant, and 
> secondly as that would cause it not to work with other SMSCs that 
> _are_ standard compliant.
>
>  
>
> I would suggest that we either implement a 'quirks' setting as I 
> suggested in the 'SMPP data coding' thread to also handle that, or use 
> the already existing alt-charset setting to catch that for broken SMPP 
> server implementations
>
>  
>
> --
> Oded Arbel
> m-Wise mobile solutions
> [email protected]
>
>  
>
> +972-9-9581711 (116)
> +972-67-340014
>
>  
>
> ::..
> As long as there are ill-defined goals, bizarre bugs, and unrealistic
> schedules, there will be Real Programmers willing to jump in and Solve
> The Problem, saving the documentation for later.
>
>  
>
> -----Original Message-----
> From: Dedy Sutanto [mailto:[email protected]]
> Sent:Wednesday, October 02, 20026:43 AM
> To: [email protected]
> Subject: [PATCH] Chararcter @ in SMPP
>
> Dear all
>
>  
>
> I’d like to propose patch to fix problem with character @ in SMPP.
>
> Since, I read from kannel userguide.html, the character @ in SMPP has 
> sign “y?”. It means “driver probably has this feature, has not been 
> tested”.
>
> Then I tested it. The conclusion is the problem seems still there 
> because kannel mapping “@” to “I”.
>
>  
>
> This patch will patch file charset.c (below dir /gwlib). I notice that 
> smsc_smpp.c use character set defined in charset.c file.
>
> I modified character mapping (for @) in charset.c.
>
> I already use this patch since 1.2.0 in CVS (maybe since 1.1.6 – don’t 
> remember) and it work for me. I used it for my sms to mail and mail to 
> sms services.
>
>  
>
> Please take a look on this patch, because I only test it in SMPP 
> environment.
>
> I am afraid this patch affects other driver.
>
>  
>
>  
>
> Kindly Regards
>
> -dedy-
>
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.