Re: DLR sync issues with EMI

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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>