Hi list,
ok, we have currently 2 approachs in "solving" the issue that Vincent presented
to the table again in his mail:
Subject: [PATCH] DLR with field_dst not supported in Mysql/Pgsql
Msg-Id: <[EMAIL PROTECTED]>
concerning the fact that DLR lookups and manipulations are not done in the DLR
repository space due to the fact that SMPP may return a different MSISDN scheme
in DLR reports.
The approaches (in order of historical appearance ;)
1) Alex's approach to strip away the country and network part. Hence the string
that is used for the SQL statements will remain the base MSISDN number of the
mobile. Something like this:
strip = (octstr_len(dst) > 10 ? octstr_len(dst) - 10 : (octstr_len(dst) > 7 ?
octstr_len(dst) - 7 : 0));
and then use
sql = octstr_format("SELECT <...> FROM %s WHERE <...> AND %s like '%%%s';",
..., octstr_get_cstr(dst)+strip);
This does work. But it's not fail safe. The probability that we run into
collisions is drastically reduced.
2) Oliver's approach to use smsc-id level normalization via 'unified-prefix'
config directives. For the patch see
Msg-Id: <[EMAIL PROTECTED]>
Votes for the approaches? Opinions please.
Personally, I like 2) but I admit I agree to Alex in the "more user
configuration is bad" comment. A user that is not aware of the implication that
he has to handle MSISDN normalization for the DLR lookup handling (even while we
could dedicate a user's guide section to this) will run into errors, even while
he wouldn't too.
I guess there is no full automatic way in normalizing MSISDN schemes as used in
the real world.
I'd like to go for approach 1) at first step. This has been tested in extends
and would also go into 1.4.1 stable.
Option 2) and further conceptional considerations could lead us to a even better
and hopefully totally fail safe solution.
Stipe
-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------
