Re: [PATCH] dlr_mem.c & dlr_sdb.c check for dst

On Wednesday 31 March 2004 15:33, Nicholas Rahn wrote:
> ok, that makes sense to me.  basically strip down the octstr to 10
> characters and then use a like clause in the sql query.  i think this
> would work for my usage and as far as i can tell (which might not be too
> far :-) would not break current usage.
>
> do you already have this change made for the other dlr types (mem,sdb)?
> if not, i can make a patch for the dlr_sdb and dlr_mem types.

nope, we are using mysql only... mysql is really faster for dlr's...
feel free to make a patch.

>
> thx
> nick
>
>
> ps. just looked at the code for dlr_oracle and it seems to be performing
> the check on the full destination number:
>
>     sql = octstr_format("SELECT %S, %S, %S, %S, %S, %S FROM %S WHERE
> %S=:1 AND %S=:2 AND %S=:3 AND ROWNUM < 2",

hmm, that's bad :( and should be fixed...

>
> On Wed, 2004-03-31 at 14:56, Alexander Malysh wrote:
> > heh, I should really find time to merge our changes ;)
> > We do some magic:
> >
> > static struct dlr_entry* dlr_mysql_get(const Octstr *smsc, const Octstr
> > *ts, const Octstr *dst)
> > {
> > ...
> >     int strip = (octstr_len(dst) > 10 ? octstr_len(dst) - 10 :
> > (octstr_len(dst) > 7 ? octstr_len(dst) - 7 : 0));
> >    query = octstr_create("SELECT ... WHERE ... AND %s like '%%%s'",
> > 	octstr_get_cstr(field-dst), octstr_get_cstr(dst)+strip);
> > ...
> > }
> >
> > because destination is always really phone number and phone number is as
> > rule
> >
> > > 10 we are safe here.
> >
> > Just as example Vodafone germany:
> > sent: 00491721111111
> > dlr: 01721111111
> > dlr-lookup: like '%1721111111'
> >
> > P.S. If oracle dlr module makes lookup with a full destination number
> > then it's bug and should be fixed asap...
> >
> > On Wednesday 31 March 2004 14:43, Nicholas Rahn wrote:
> > > To answer part of my own question, it seems to me that the reason I
> > > don't have the "+" character as part of the destination field of the
> > > dlr is because the dlr destination field never passes through the
> > > "normalize_number" function as the sender/receiver fields of mo/mt
> > > messages do.
> > >
> > > digging a bit deaper in the code shows that the normalization of the
> > > destination dlr field might be best done in the "dlr_find" function. 
> > > of course, this might break some people's dlr configurations.
> > >
> > > anyone have any thoughts on this?  is modifying the dlr_find function
> > > to normalize the dlr destination field a good or a bad idea?
> > >
> > > nick
> > >
> > > On Wed, 2004-03-31 at 10:32, Nicholas Rahn wrote:
> > > > Hi,
> > > >
> > > > This patch adds the check for the destination to dlr verification in
> > > > internal and sdb storage.  As more than one sms can be sent with the
> > > > same timestamp and smsc-id, these are not enough to ensure unicity of
> > > > the dlrs.  So, as Robert Galach did for dlr_oracle.c, this patch adds
> > > > the destination number to the check.  NOTE: mysql is now the only dlr
> > > > storage that does not use this approach.
> > > >
> > > > One thing i have noticed is that the CIMD2 smsc that i connect to
> > > > accepts a destination number in international format (i.e. +41).
> > > > However, the dlr received back from the SMSC does not contain the "+"
> > > > character.  So now (with my patch above :-), none of the received
> > > > dlrs match!  Can anyone suggest a solution to this?
> > > >
> > > > Thanks,
> > > > nick

-- 
Best regards / Mit besten Grüßen aus Düsseldorf

Dipl.-Ing.
Alexander Malysh
___________________________________________

Centrium GmbH
Vogelsanger Weg 80
40470 Düsseldorf

Fon: +49 (0211) 74 84 51 80
Fax: +49 (0211) 277 49 109

email: [email protected]
web: www.centrium.de
msn: [email protected]
icq: 98063111
___________________________________________

Please avoid sending me Word, Excel or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html