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