> -----Original Message-----
> From: Mauricio Ramos [mailto:[EMAIL PROTECTED]]

> > DLR notification using URL triggers are "only" for informing an
> > external entitfy (from the point of view of Kannel itself). 
> bearerbox
> > relies on it's own facilities to resend failed messages.
> 
> Really?  I thought the philosofy o Kannel's DLR notification 
> is to pass the
> responsability of the retransmit to the Application!  Any way 
> I could change
> my Application to not retransmit failed messages anymore, 
> relying this task
> to Kannel, but, would Kannel keeps retransmitting the sms 
> until either it
> would be delivered or it would be expired?  Is there such mechanism?

AFAIK - Kannel does not have a mechanism to "expire" messages that have past their 
validity period. the problem is much worse, I'm afraid - the decision of whether to 
retry a message or fail it completly (sending an SMSC_FAILED dlr) is done by the 
module, where most often it fails the message delivery if it doesnot succeed in 
sending the message on the first try. Another important point, is that if the sending 
failed and the module decides that it should retry the message, you wouldn't get an 
SMSC_FAILED dlr (you could, but it is not coded that way).

> Again, that's the way I thought Kannel works.  Negative Acknowledge
> notifications would pass to an external Application the 
> responsibility to
> decide weather to retransmit the message (sendsms again) or 
> give up (do
> nothing).  If Kannel does take care of the resending process, at least
> Kannel must have a configurable mechanism to do that (How 
> many times/For how
> much time/In which interval) because if not, Kannel would eventually
> interfere in business rules of an specific Application.

That is how it is done. AFAIK, modules only try to resend if the sending failed 
because of connection problems. when you receive an SMSC_FAILED message - the module 
has given up on trying to ever send that message.

> Exactly! And if it's a message impossible to be delivered (ex. with an
> invalid dest address), Kannel will keep it forever until I drop the
> store-file.  How we "killall -HUP" every 0:00am, Kannel 
> restart do reading
> the store-file and resend all those old failed message again, 
> so every day
> the avalanche is bigger, producing throtling errors on SMSC's 
> side and HTTP
> connector errors on DLR-URL application's side.

That is a bug in the SMSC module and need to be fixed. messages that are malformed 
should be removed from the store file.

> Does any SMPP specialist knows if I use the validity 
> parameter of sendsms
> would make Kannel stop to keep resending the message to SMSC 
> accordingly?

no - that would not work.

--
Oded Arbel
m-Wise mobile solutions
[EMAIL PROTECTED]

+972-9-9581711 (116)
+972-67-340014

::..
"For a successful technology, reality must take precedence over public relations, for 
Nature cannot be fooled." 
        -- R. P. Feynman

Reply via email to