RE: Question regarding DLR

Hello,

i found a another Issue with that Problem.

Both UPDATE and DELETE are also working with SMSC-ID and TS only. Both are
limited to only one row which is good but since any SMS of the those whith
same SMSC-ID and TS could be updated/deleted...

I also realised that if you use DLR status 8 and 16 only, all of this isn't
a Problem since no Timestamp is used. For EMI2/UCP the SMSC-ID +
Windownumber is used, since those DLRs are an instand on each window all
works normal.

The Problem occurs only if you use Real DLR through your partners SMSC.

We are only using UCP with DLR. So i can't say if there are others/same
Problems with other protocols.

I hope my english isn't as bad as i think and it is quite understandable
what i want to address.

Kind Regards,
 Stefan Haubold

> -----Ursprüngliche Nachricht-----
> Von: Stefan Haubold [mailto:[email protected]]
> Gesendet: Donnerstag, 18. November 2004 14:32
> An: [email protected]
> Betreff: Question regarding DLR
>
>
> Hello,
>
> i have a question regarding DLR with MySQL Storage. We are using
> Kannel 1.3.1 but the Problem is also in 1.3.2 (i checked the cvs)
>
> If i get everything right, the SELECT for finding a Delivery
> Notification checks for SMSC-ID and TS.
> Isn't that a Problem, if Kannel is working on "Fullspeed"?
> For example if Kannel send 6 SMS per Second over one SMSC you get
> 6 DLR Entries with the same SMSC-ID and the same TS. If all those
> 6 SMS are delivered/accepted Right, all DLR will be handled and
> it looks as everything is ok. If one SMS can't delivered or is
> delayed Kannel isn't able to mark the right SMS of those 6 SMS
> since the SELECT isn't deterministic it will return any of that 6 SMS.
>
> I checked through the Source a few times but haven't found any
> clue if there is something i miss.
>
> I patched Kannel to add DESTINATION to the WHERE clause of that
> SELECT. But this isn't perfect too, since sending Multipart SMS
> could  leave also more then 1 SMS with equal SMSC,TS and
> Destination. I think that this is an acceptable risk since if all
> go ok its fine, if one gets lost the hole Multipart SMS is lost.
>
> So please tell me if i miss anything. If not, maybe you should
> consider adding that Patch to the Source Tree.
>
> Kind Regards
>
> Mit freundlichen Grüßen
> YOC AG
>
> --------------------------------
> Stefan Haubold
>
> YOC AG
> Dircksenstr. 47
> 10178 Berlin / Germany
> Tel: +49-30 72 61 62-401
> Fax: +49-30 72 61 62-222
>
> mail to: [email protected]
> visit us at: www.yoc.de / www.yoc-ag.de
> Login mit Alter und Geschlecht per SMS unter 72768
>
> yoc - dein wille geschehe.