Hello Niko, all Yes I can verify that this happens with all CIMD2 SMSCs. In our installation we connect with 5 SMSCs simultaneously and we have been loosing DLRs from all of them until fixing the classes I sent you (the exact brand(s) of the SMSCs are unknown to me).
You are right that it is not correct to select dlr-url based on the whole destination number, since it is mangled by a lot of SMScs. In our case SMSCs returned DLRs containing SMS recipient MSISDN in international format regardless of the MSISDN format we have provided (in our case national format) when sending the original SMS. I hope that the patch you mention addresses this issue also although i am interested to see how the patch handles all available numbering plans! BRs On Tuesday 13 July 2010 13:18, Nikos Balkanas wrote: > Hi Byron, > > Unfortunately the patches you submit are not in the correct format to be > accepted by kannel. For more info check the site. > Besides, a patch to address the same exact issue has been submitted for the > case of EMI/UUCP and waits final correction and approval. It could easily > cover CIMD2 as well. Besides, it is wrong to select based on the whole > destination number, since it is mangled by a lot of SMScs. > > You are correct that the Oracle driver is currently different and not > aligned with the rest. However, it is still not correct, since it matches > the whole destination number in the query, which is error-prone and misses > DLRs. This is also addressed in the submitted patch. Patch won't correct > the case that you have a lot of SMS sent to the same receipienet through > the same SMSc at the same second. This requires another fix outside DLR > code. > > Indeed SMPP has solved this problem by requiring a unique id in their spec. > > Can you verify whether this happens with all CIMD2 SMScs, or just some of > them? > Since I am ready to submit final patch corrections, your timely answer > would be needed to include CIMD2 support in the patch. > > BR, > Nikos > > > ----- Original Message ----- > From: "Byron Kiourtzoglou" <[email protected]> > To: <[email protected]> > Cc: <[email protected]>; <[email protected]>; <[email protected]>; > <[email protected]> > Sent: Tuesday, July 13, 2010 12:21 PM > Subject: Lost DLRs > > > Hello all, > > > > We had the same problem with unhandled DLRs in one of our installations, > > see > > Thread : http://www.mail-archive.com/[email protected]/msg20441.html (the > > second issue) > > > > We use the latest stable version of Kannel (1.4.3) and the CIMD2 protocol > > to > > communicate with the SMSC. > > > > After investigating the code we figured out that for all MT SMS with > > dlr-url > > specified, Kannel uses the SMSC id and the send time (timestamp in > > seconds > > precision) of the original MT SMS to correlate incoming DLRs with the > > provided dlr-url for callback. Thus If you send more than one MT SMS from > > the > > same SMSC within the same second Kannel wont be able to distinguish > > between > > the available dlr-urls to invoke, upon DLR retrieval. What we experienced > > is > > wrong drl-url callback and even no drl-url callback at all. > > > > The interesting thing is that the aforementioned behavior is not applied > > when > > using Oracle DB for storing DLRs, due to the fact that correlation is > > performed based on the triplet : SMSC id - timestamp - MT SMS receiver > > address (well to be absolutely honest we must state than even for this > > case > > if you send more than one MT SMS to the same recipient within the same > > second > > and from the same SMSC then the problem will still exist). > > > > Furthermore this behavior is not applied when using the SMPP protocol > > because > > the correlation between the MT SMS and the DLR is done based on the SMSC > > id > > and a unique number (auto increment number for every MT SMS send). > > > > To correct the problem we have altered all classes that handle DLRs by > > adding > > the MT SMS recipient address to the correlation algorithm. Thus only if > > you > > send more than one SMS to the same recipient within the same second and > > from > > the same SMSC, using the CIMD2 protocol you should experience dlr-url > > callback issues. > > > > We attach all altered files > > > > > > BRs > > > > -- > > Byron I. Kiourtzoglou > > > > Electrical & Computer Engineer > > Msc Business Administration > > > > Senior Software Engineer > > Business Support Systems Department, Engineering Unit > > > > INTRACOM TELECOM > > 19.7 km Markopoulou Ave. > > 19002 Peania, Athens, Greece -- Byron I. Kiourtzoglou Electrical & Computer Engineer Msc Business Administration Senior Software Engineer Business Support Systems Department, Engineering Unit INTRACOM TELECOM 19.7 km Markopoulou Ave. 19002 Peania, Athens, Greece
