On Tue, November 28, 2006 10:29, Thomas Göttgens wrote:
> Tuesday, November 28, 2006, 8:47:06 AM, you wrote:
>
>
> TS> .. or any other storage for that matter - the only thing used to
> match in TS> internal (mem), mysql and pgsql is 'ts' and 'smsc'
>
>
> I'm seeing the same erratic behaviour here running a pool of 5
> symmetric UCP connections to a single SMSC. My problem is that DLR's often
> come down a different link than the original SMS was sent to, so i had to
> nake all SMSC's in the pool the same, in order for them to use a common
> storage.
>
> Now, with only checking smsc and ts, and a throughput of 5 sms/s per
> link, i often get false DLR reports and URL calls from kannel. Can this
> behaviour be modified to include at least the destination number or is
> there another solution to 'pool' connections like I require?
Attached is a simple patch I just made, it only works if your dlr storage
is set to "internal" (or nothing), but it pretty much solves all the
problems.
If you use a different storage method, you'd need to apply the same
functionality to that, depending on which storage.
// Tom Sommer
// http://www.tomsommer.dk
--- org/gateway-1.4.1/gw/dlr_mem.c 2005-02-11 16:35:48.000000000 +0100
+++ gateway-1.4.1/gw/dlr_mem.c 2006-11-28 09:24:24.000000000 +0100
@@ -125,7 +125,7 @@
/* 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)
+ if(octstr_compare(dlr->smsc,smsc) == 0 && octstr_compare(dlr->timestamp,ts) == 0 && octstr_compare(dlr->destination,dst) == 0)
return 0;
return 1;
