Re: {PATCH] final smsc-id passing in ack msg type

Hi,

It seems to me like the request by Elton Hoxha. Being both SMSc and ESME 
admin, he wanted to minimize both loads and avoid DLRs all together, in the 
case of bulk SMS.  He needed, though, the FID. The question was if he could 
rely on logs for that.

He was rather surprised to find out that he couldn't.

I reckon the following. If a user doesn't request DLRs, he should still get 
the FID from the ack. If he requests DLRs, he may end up with a bunch of 
FIDs, and he can choose whichever he prefers. As a compromise, from within 
kannel, if dlr-mask is 0, FID can be taken from the ACK. Else ditch that and 
wait for the DLR.

BR,
Nikos
----- Original Message ----- 
From: "Stipe Tolj" <[email protected]>
Cc: "kannel_dev_mailinglist" <[email protected]>
Sent: Saturday, March 21, 2009 12:53 PM
Subject: Re: {PATCH] final smsc-id passing in ack msg type


> Alexander Malysh schrieb:
>> we have already callback infrastructure, it's called DLR :)
>> I don't see sense in this feature because all this could be done with
>> already implemented
>> and well known method DLR.
>
> I object. This "can" be done with DLR, but "only" if DLRs are requested. 
> It's
> still legitime to provide the assigned smsc-id in the ack msg back, even 
> if NO
> DLR is requested.
>
> Yes, you could make the dlr-mask that way that you get only the "SMSC 
> accepted
> the msg" DLR atually. But this implies we have doubling the load on the 
> internal
> message bus between bearerbox and smsbox. That's not really effective IMO, 
> as
> the ack msg is anyway passed back to the smsbox for the MT push and we 
> simply
> ditch in another value.
>
> Stipe
>
> -- 
> -------------------------------------------------------------------
> Kφlner Landstrasse 419
> 40589 DΟsseldorf, NRW, Germany
>
> tolj.org system architecture      Kannel Software Foundation (KSF)
> http://www.tolj.org/              http://www.kannel.org/
>
> mailto:st_{at}_tolj.org           mailto:stolj_{at}_kannel.org
> -------------------------------------------------------------------
>