Re: [PATCH] include destination into dlr lookup

Hi,

Nicholas Rahn wrote:

> I just had a chance to look at this code and i don't think this will
> work for swiss or french numbers.  in switzerland there are 10 numbers
> in a national number (i.e. "0761234567").  If this is what we receive
> from the SMSC, the patch will strip it down to 7 numbers ("1234567").
> the last 7 characters are not enough to guarantee unicity. Only the
> first 3 characters (of the 10) are what determine the operator network
> in switzerland and thus we could have 2 stripped numbers that are the
> same (ex. 0761234567 and 0791234567 would both strip to 1234567).

yep, as discussed with Guillaume in private conversation, we could expand my
patch to strip > 9 then... but anyway, my patch doesn't guatantee unicity
(hmm, we can never guarantee unicity... just think about a case: you sent 2
msgs to the same dst number in the same second over UCP link. which dlr
entry would you pick from dlr storage when first dlr arrive?)

> 
> back in april i suggested the following solution:
> 
> Remove any "00", "0" or "+" prefix from the destination and use this in
> a like clause in dlr_find.

hmm, I thoughts about such implementation too... Would this work only for
europe or for most countries in the world? I was not sure, but the idea is
worth to think about?! I'm relly +1 if it would work at least for the whole
europe...

> 
> this is very similar to the current patch (still requires the LIKE
> clause, but i'm not too concerned about that).  and it would solve the
> problem mentioned above, making the patch usable for more people.
> 
> any thoughts?

yep, see above ;)

Thanks for your comments!

> nick
> 
> 
> On Tue, 2004-09-28 at 13:39, Enver ALTIN wrote:
>> Hi,
>> 
>> On Tue, 2004-09-28 at 13:37 +0200, Alexander Malysh wrote:
>> > I don't like the idea of bloating the db and we will not win too much
>> > performance (IMHO)... (we should really make benchmarks with
>> > direct/indirect db lookup)
>> 
>> I'm fine either way, as long as it works :)
>> 
>> Thanks,

-- 
Thanks,
Alex