Re: DLR sync issues with EMI

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