On Monday, 18 בJuly 2005 21:50, Stanislav Sinyagin wrote: > --- Oded Arbel <[EMAIL PROTECTED]> wrote: > > I think you have a confusion as to what is DLR. > > would be nice to have more explanation here. Is it for reporting > only, and not for storing the queue of those not yet delivered?
DLR is about getting delivery reports from the SMSC to the status of your message. SMS is a "store and forward" service. that means its asynchronous and you generally not supposed to know immediately whether your target has received the message or not. What you actually do, is submit the message to kannel's smsbox. this transfers the message to the bearerbox where it is stored and you get a reply saying "thanks for submitting the message - we have stored it and will try to send it out as soon as we have the opportunity". So far so good. But you really want to know whether the message was received and what happened to it on the way. If it wasn't received you probably want to resend it. So this is where "delivery reports" aka DLR comes into play. Kannel supports several levels of DLRs, which you specify using the dlr_mask in the smsbox's sendsms call. If all DLR levels are enabled and you specified the dlr_url where you want DLR message to be delivered back to you, then kannel will call you back (on that url) when it detects the following events occurring: - Kannel has managed to submit your message to the SMSC (ACK) - Kannel has failed to submit your message to the SMSC (NACK) - The SMSC reported that the message could not be delivered in a timely manner and will be stored for indefinite time on the SMSC until delivery is possible (BUFFERED) - The SMSC reported that the message was successfully submitted to the recipient (SUCCESS) - The SMSC reported that the message was not submitted to the recipient and no further attempts will be performed (FAILED) The first two statuses are handled internally by Kannel and require only the most rudimentary support from the driver (basically being nice enough to generate the required message when you receive acknowledge or rejecting on your protocol). Every driver currently in the main tree does that. The other two stages are more complicated - the driver has to speak the lingo of the SMSC well enough to let the SMSC know that it is interested in receiving further information on the status of the message as it is handled by the SMSC (according to the dlr_mask). The SMSC needs to support that capability, and the driver needs to be able to receive and understand the notifications sent by the SMSC. the AT driver currently fully supports this by setting the required flags on the message as it is being sent, and parsing the corresponding GSM messages as their are forwarded by the modem to Kannel. In any case, DLRs do not govern retransmit and kannel has no mechanisms to do that anyway. once the message is being handled by the driver, as soon as the driver can determine if the message was accepted or rejected by the SMSC it is removed from the storage (regardless of actual status). If you want a retry mechanism you have to do it yourself by catching DLR messages and resending. The AT driver itself has a simple mechanism where if the GSM modem refuses to accept the message in the first try, two additional retries are made, assuming that sometimes the modem, being the slow device that it is, does not accept the message because it is currently busy doing other things (for example - receiving other messages), and by retrying with a slight delay, we can still successfully submit the message. sometimes it even works :-) If all 3 tries have failed, a NACK message is being sent (but not before that). > > Anyway - the new AT driver (which was at2 previously) has full > > support for DLRs as of version 1.3.2 IIRC > > ah, right. sure, I just looked in the docs and saw there it's set as > not suppprted, and I actually din't see any DLR entries while the SIM > card was not inserted - I expected to see them as queued. First, you need to set dlr_mask and dlr_url properly. Then, in the case of the SIM card not inserted, you will only receive the NACK response - this is a final status and as kannel cannot successfully submit the message to the SMSC, no further DLR statuses will be available. If by "queued", you mean "BUFFERED", then that is an SMSC status and can only be received after an ACK. if by "queued" you mean, "stored by kannel for deliver", then the answer is that this status is implicit for each message and kannel does not generated DLRs for that. Once the message is received by the driver and the driver fails to send it to the modem (because there is no sim), the message is discarded and a NACK DLR is sent. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9611212 (204) +972-54-7340014 ::.. Godwin's Law (prov. [Usenet]): "As a Usenet discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one." There is a tradition in many groups that, once this occurs, that thread is over, and whoever mentioned the Nazis has automatically lost whatever argument was in progress. Godwin's Law thus guarantees the existence of an upper bound on thread length in those groups.
