Very true, perhaps an optional setting to allow stricter matching of DLR, using the dst value?
I've been running with my patch for the past week without issues. // Tom On Fri, December 1, 2006 20:13, Andreas Fink wrote: > the issue as far as I remember with the destination number is that the > delivery report might come back with another number. > > Example: you send to 00417912345 (international format) on a swisscom > SMSC, it might get you a delivery report of 07912345 (national > format). So then we NEVER match which is no good neither. I'm sure some > universal numbering stuff could fix this but its another pitfall for > enduser who are not aware of those things. > > On 28.11.2006, at 08:47, Tom Sommer wrote: > > >> .. or any other storage for that matter - the only thing used to >> match in internal (mem), mysql and pgsql is 'ts' and 'smsc' >> >> // Tom >> >> >> On Tue, November 28, 2006 08:43, Tom Sommer wrote: >> >>> From gw/dlr_mem.c: >>> >>> >>> >>> /* >>> * Private compare function >>> * Return 0 if entry match and 1 if not. >>> */ >>> static int dlr_mem_entry_match(struct dlr_entry *dlr, const Octstr >>> *smsc, >>> const Octstr *ts, const Octstr *dst) { /* XXX: check destination addr >>> too, because e.g. for UCP is not enough to check only * smsc >>> and timestamp (timestamp is even without milliseconds) */ >>> if(octstr_compare(dlr->smsc,smsc) == 0 && octstr_compare(dlr- >>>> timestamp,ts) >>> == 0) >>> return 0; >>> >>> return 1; } >>> >>> >>> >>> which means there is no check performed on dst if you use internal dlr >>> storage. >>> >>> // Tom >>> >>> >>> >>> On Mon, November 27, 2006 22:57, Andreas Fink wrote: >>> >>> >>>> >>> >>>> This is a known limitation of EMI/UCP protocol. The timestamps are >>>> not unique on a EMI SMSC. to avoid this, dont send to the same number >>>> a content in the same second as you will get the same timestamp and >>>> same destination number in the delivery report and Kannel will have >>>> no way to distinguish them. >>>> >>>> >>>> On 27.11.2006, at 13:58, Tom Sommer wrote: >>>> >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> >>>>> I'm having some problems with DLR reports not landing at the >>>>> correct DLR url assigned during transmission of the SMS. >>>>> >>>>> Basically if two SMS messages are sent at the same time, >>>>> receiving the same timestamp, it appears mixups can happen when >>>>> the time comes to transmit DLR messages. >>>>> >>>>> Obviously it appears the problem is the date, so perhaps a >>>>> solution would be to add the dst value to the DLR matching, >>>>> thereby avoiding errors like the described. >>>>> >>>>> Thoughts? >>>>> >>>>> >>>>> >>>>> >>>>> // Tom Sommer >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> > >