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