> > 2) Why did kannel do it if it had been notified to My > Application which is > > responsible to do that? > > 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? > Some of the SMPP gurus arround here? > > I guess we may drop the message if an neg-ack is received by the SMPP > server side, right?! This would avoid the resending of a "broken" > message. But this would only avoud resending if DLRs have been > requested and DLRs are not requested by default. Hmmmm.... Hence we > can't distinguish here IMO. That's a logical problem. 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. I still don't what Kannel actually does regarding the resending process. I would like to understand it precisely. > > so the message keeps to be in the store file forever here. 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. 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? > I guess the failed messages should have been logged to access.log as > "failed" and extracted from the DLR queue, right?! > Which then means when the DLR notification comes in, the DLR logic > will not find the message in the current queue any more. Right, and that happens if my Application doesn't ask for delivery notification, not using dlrmask field in sendsms cgi. I'm starting to think that the sendsms's validity parameter could be a good workaround, I'll try it. > Your SMSC provider seems to deliver the information "your destination > addr is invalid" twice, one time directly via the submit_sm_resp PDU > error code and one time via a DLR messages which you have requested. Really? Did you see that in this 3 lines: 2002-08-20 16:54:02 [6] ERROR: SMPP[CARRIER]: SMSC returned error code 0x0000000b in response to submit_sm. 2002-08-20 16:54:02 [6] INFO: SMPP[CARRIER]: creating DLR message 2002-08-20 16:54:02 [6] INFO: SMPP[CARRIER]: DLR = 0x0000000b/http://localhost I understood all are the same thing. SMSC returned 0x0000000b on submi_sm_resp PDU and then a DLR notification was sent to http://localhost. One is a consequence of the other, isn't it? > Any ideas from the others how this can be resolved to be more > semantic? > > Stipe Thank you very much, as allways Best regards, Mauricio.
