Re: Fwd: DLR sync issues with EMI

"Tom Sommer" <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <[email protected]>
>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
>>
>>
>>
>
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.