Alex, Recently i had the case that a DLR were wrongly updated.
2005-12-21 08:00:11 [2436] [16] DEBUG: DLR[mysql]: Looking for DLR smsc=SMSC-1, ts=211205080007, dst=<masked>, type=2 2005-12-21 08:00:11 [2436] [16] DEBUG: sql: SELECT mask, srvc, url, src, dest, boxc FROM dlr WHERE smsc='SMSC-1' AND ts='211205080007'; 2005-12-21 08:00:11 [2436] [16] DEBUG: sql: DELETE FROM dlr WHERE smsc='SMSC-1' AND ts='211205080007' LIMIT 1; 2005-12-21 08:00:15 [2436] [16] DEBUG: DLR[mysql]: Looking for DLR smsc=SMSC-1, ts=211205080007, dst=<masked>, type=1 2005-12-21 08:00:15 [2436] [16] DEBUG: sql: SELECT mask, srvc, url, src, dest, boxc FROM dlr WHERE smsc='SMSC-1' AND ts='211205080007'; 2005-12-21 08:00:15 [2436] [16] DEBUG: sql: DELETE FROM dlr WHERE smsc='SMSC-1' AND ts='211205080007' LIMIT 1; On a hudge systems, ts are in many case the same as many MTs (on a same SMSC). Do you really think that most of DLR should be wrong just because of a few SMSC thats are returning wrong ADC ? IMHO, it does not break all existing installations as you may think, it will just not found the DLR into the DB... but i think this is really acceptable. Vincent. ----- Original Message ----- From: "Alexander Malysh" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, January 10, 2006 12:10 PM Subject: Re: [PATCH] DLR with field_dst not supported in Mysql/Pgsql > Dear Vincent, > > did you find the previous discussion about this issue? If not please > find it in ML archive read carefully and then make your statements. > > The problem is simple. UCP/SMPP does not define how destination address > should be returned in delivery report. It does not explicitely say: it > _must_ be equal. So you have no right to say those SMPP/UCP servers are > buggy (ok, I would say it too, but...). And we (developer) have no right > to break existing installation w/o a good reason and yes I see good > reason to use destination in select, update, delete but not so how you > do it. Destination should be stripped for some chars at beginning and > only then used in select/update/delete. > > Thanks, > Alex > > P.S. Please also see my patch for this topic in archives. > > > Vincent CHAVANIS wrote: >> Dear, >> >> Alex i understand your point of view,but it's better to not found a DLR in >> the DB than updating a wrong one... (safety) >> It breaks compatibility with broken UCP servers that allow to change the >> OAdC field, YES >> But, many UCP servers does not allow this. SMSC should return the AdC as >> mentionned in UCP 51 >> That's why i think that this feature should be implemented. >> >> regards >> >> Vincent >> >> -- >> Telemaque - NICE >> Service Technique >> Tel : +33 4 93 97 71 64 (fax 68) >> [EMAIL PROTECTED] >> >> ----- Original Message ----- >> From: "Alexander Malysh" <[EMAIL PROTECTED]> >> To: <[email protected]> >> Sent: Tuesday, January 10, 2006 11:33 AM >> Subject: Re: [PATCH] DLR with field_dst not supported in Mysql/Pgsql >> >> >> >>>Hi Stipe, >>> >>>why did you commit this pacth w/o waiting a bit for comments? >>> >>>such patch was already discussed few times and we did not found solution >>>yet. I'm -1 for this patch because it will break too many installations. >>>For short explanation why -1: if you sent destination 00491234567 but >>>SMSC returns 01234567 as destination (IIRC this is the case T-Mobile >>>germany UCP server) then you will not find DLR in the DB. For a longer >>>explannation seek in ML archives for discussion about it. >>> >>>Please revert it or I will do it. >>> >>>Thanks, >>>Alex >>> >>>Stipe Tolj wrote: >>> >>>>Vincent CHAVANIS wrote: >>>> >>>> >>>>>Dear, >>>>> >>>>>I've noticed today that field_dst is not implemented in DLR for mysql >>>>>and pgsql. >>>>>If a DLR arrives with the same TS as another one on a same SMSC, >>>>>kannel will not be able to update the correct one >>>>> >>>>>Here is a patch tested and in production status, maybe should be >>>>>commited to CVS >>>> >>>> >>>>Hi Vincent, >>>> >>>>yep, ++1 here. Commited to CVS. >>>> >>>>A kind request, please do not cross-post to both lists, and we'd prefer >>>>'diff -u' format patches ;) >>>> >>>>Stipe >>>> >>>> >>> >>> >>> >> >> >> > > >
