Well, a good place to start would be to subscribe to [email protected]. And
avoid using vm1.kannel.org.
In that case unified prefix should work. Try it.
And I believe that the expression goes:
"Like a cow walking through a palace...";-)
BR,
Nikos
----- Original Message -----
From: "Luis Tiago Rico" <[email protected]>
To: "'Nikos Balkanas'" <[email protected]>; <[email protected]>
Sent: Wednesday, May 05, 2010 7:26 PM
Subject: RE: EMI DLR uniqueness, smsc-id/timestamp problem
Hi again Nikos,
Sorry if I was miss understood.
The problem is I send a MT to the smsc with the prefix, and the smsc returns
a dlr with destination without the prefix!
So I have entry on dlr DB with prefix and my query has to reflect that.
Again I agree with you with some kind of dlr-unified-prefix configuration
per smsc.
My big problem here is where to start changing the code for adding new
configurations, has I opened the project and I feel like "a cow watching to
a palace" :) ...Seems I have to lose some hours of sleep!
Feel free to do any comments!
BR,
Luis Rico
PS: I think this thread is about to go to dev...
-----Original Message-----
From: Nikos Balkanas [mailto:[email protected]]
Sent: quarta-feira, 5 de Maio de 2010 16:14
To: Luis Tiago Rico; [email protected]
Subject: Re: EMI DLR uniqueness, smsc-id/timestamp problem
But...You mentioned that some of your smscs don't send it. That's why I
proposed it. Otherwise it could be another configuration task, this time per
smsc. It is more efficient to truncate it in the code than in the database.
BR,
Nikos
----- Original Message -----
From: Luis Tiago Rico
To: 'Nikos Balkanas' ; [email protected]
Sent: Wednesday, May 05, 2010 5:56 PM
Subject: RE: EMI DLR uniqueness, smsc-id/timestamp problem
Hi again Nikos,
Thanks for the kick reply.
Well let΅―s see if got time to do all thatΞ…Β
Do you think unified-prefix configuration also works on received DLR
destination number? I was looking exactly that on the manual and nothing
mention about DLR, only MT and MO!
BR,
Luis Rico
From: Nikos Balkanas [mailto:[email protected]]
Sent: quarta-feira, 5 de Maio de 2010 15:10
To: Luis Tiago Rico; [email protected]
Subject: Re: EMI DLR uniqueness, smsc-id/timestamp problem
Hi,
Since you do not seem shy to go through the code, why don't you try making
the patch configurable? As far as prefices go, look into the unified-prefix
variable in configuration. That way kannel will strip off the extra prefix
and do an exact match.
BR,
Nikos
----- Original Message -----
From: Lu¨s Tiago Rico
To: [email protected]
Sent: Wednesday, May 05, 2010 5:02 PM
Subject: FW: EMI DLR uniqueness, smsc-id/timestamp problem
Hi Nikos,
Thank you for your reply.
I was already guessing why the patch was not includedΞ…Β Never the less, I
will download the src code from cvs, and apply the patch to produce my
releaseΞ…Β
I will have to change it a bit more, because some of my smsc don΅―t send
the
country code prefix on destination numbers, like I send on the MT, so I need
to include them in dlr search. I could put a Ξ…Β°LIKE %destinationΞ…Β±
condition
on the query, but I don΅―t want to slow down performance΅ What do you
think?
As you say, it will be great to include on the smsc configuration some
property that if set would include the destination number on the dlr search
query (or something like that).
BR,
Luis Rico
From: Nikos Balkanas [mailto:[email protected]]
Sent: quarta-feira, 5 de Maio de 2010 10:57
To: Luis Tiago Rico; [email protected]
Subject: Re: EMI DLR uniqueness, smsc-id/timestamp problem
Hi,
This is a known issue with DLRs. Ts is supposed to be a unique "foreign-id",
not a timestamp, at least with SMPP. Some time ago a patch was provided to
include also destination number into DLR matching. However, that clashed
with existing SMScs, which do not report destination numbers in their DLRs,
so i guess never made it to CVS.
Maybe this patch needs to be configurable in each SMSc.
BR,
Nikos
----- Original Message -----
From: Lu¦�s Tiago Rico
To: [email protected]
Sent: Tuesday, May 04, 2010 9:19 PM
Subject: EMI DLR uniqueness, smsc-id/timestamp problem
Hi to all,
I'm using Kannel 1.4.3 and I'm having this problem with some
switched/mismatch delivery reports! It happens when I send several MT to the
same SMSC at the same time, using a EMI connection...
Well, from what I got, when a DLR arrives, Kannel only takes in account the
SMSC ID and the Timestamp. This causes a loose of uniqueness, since only
timestamp and smsc-id are used as unique id (no destination number).
2010-05-04 16:54:26 [18405] [12] DEBUG: EMI2[68959-TMN]: emi2 parsing
packet:
<^B02/00368/O/53/68959/962834401/////////////040510165418/1/107/040510165422/3//4120737561206D656E736167656D206461732031363A35343A31382064652031302D30352D3034207061726120303033353139363238333434303120666F69206775617264616461206E6F2043656E74726F206465204D656E736167656E7320646120544D4E2E204D6F7469766F3A2054656C656D6F76656C206465736C696761646F20282020323729/////////////46^C>
2010-05-04 16:54:26 [18405] [12] DEBUG: DLR[pgsql]: Looking for DLR
smsc=68959-TMN, ts=040510165418, dst=962834401, type=4
2010-05-04 16:54:26 [18405] [12] DEBUG: sql: SELECT mask, service, url,
source, destination, boxc FROM dlr WHERE smsc='68959-TMN' AND
ts='040510165418' LIMIT 1;
So, if two or more messages have the same timestamp, it's not guaranteed
that the arrived DLR's are matched against the correct DLR entry on database
(and then the problem spreads, as the dlr_url are wrong, etc, etc).
Correct me if I'm wrong but from my research on the mailing list I found
this problem was a old known one and there is/was a patch for it (adding the
destination number to the queries)! As I was reading a bit more on the
mailing list, I found that the problem was solved in the "after releases"...
Well it was a bit wired because in my log files the query only takes in
account the mentioned parameters... Reading a bit more I found that for some
reason the patch was not included in the latest release (see
http://www.mail-archive.com/[email protected]/msg19454.html)!
Sincerely I got a bit confused here with these patches included/not included
in the releases....
So my questions are:
Is this patch the way to solve the problem or there is something that I'm
missing here?
Why this patch was not included/forgotten in the latest kannel release
(1.4.3)?
Where can I find this patch and how to install it (just copy files / compile
kannel) ?
Many thanks in advance,
Luis Rico
