Kannel does DLR's asynchronously. This is by design, and makes a lot of sense:
1. There can be many DLR's per message (accepted, queued, delivered for example). Which one would you expect to receive? Even the first one (which is internally generated by kannel when accepting the message) could take minutes or even hours if there's a lot of traffic enqueued. 2. A lot of time can pass between the original enqueuing and final delivery: * Kannel can have a lot of messages already enqueued. (See last paragraph). * SMSC can be down or also with a lot of enqueuing. * Final recipient can have his phone off. If you don't close the session as soon as the message is accepted by kannel, you could end up with lots of connections awaiting as long as 24Hs for the final DLR. What you wan to achieve (aka synchronous delivery) does not scale at all and it's unpractical on most scenarios. You could set "immediate-sendsms-reply" to false and read the status response to determine if berarebox has accepted your message, but this will negatively impact performance for sure. You can also fake a somewhat similar behaviour by wrapping it into a script that writes to a database and waits on a row until is changed by the DLR, but don't expect to be able to sustain slighter than moderate traffic with this kind of approach. Hope it helps, Alejandro Guerrieri On Fri, Jun 6, 2008 at 8:48 PM, Yang Zhao <[EMAIL PROTECTED]> wrote: > Greetings, > > On Thu, 2008-06-05 at 07:58 +0200, Andreas Fink wrote: > > this feature exists, even though not in the way you might think. > > You can ask for a delivery report... > > This is not quite what I had queried about. I am aware of Kannel's DLR > capabilities and it is already being used. > > In case my original question was not clear, I am curious about what > changes would be required to enable content of the first DLR being sent > back as the reply to a HTTP sendsms request. (See the first comment > block of delayed_http_reply() in smsbox.c) > > > Correlating DLRs to the original sendsms request via dlr-url tricks may > be perfectly OK for some, but offloading this logic to the calling > application mandates complexities, such as unique ID generation, that > Kannel already handles internally. Imagine trying to integrate Kannel > into an environment with multiple physical machines behind a black-boxed > load balancer where requests can come from and DLR calls are made to. > Now imagine the kind of trade offs that need to be made if the calling > application _must_ know whether or not an SMS message request was > actually accepted by the external SMPP server at request time. > > > Again, I am more interested in why the internal workings of Kannel > currently prevent this from being easily added, and what can be done to > actually add it. It's not a matter of how to achieve the functionality I > want, but how to make Kannel do it in a more elegant way. > > > (Incidentally, in 1.4.1, the message_id of a submit_sm_resp PDU cannot > actually be included in the DLR, and I had to patch Kannel myself to > work around this. Unless I'm mistaken, there's no data included in the > DLR that can be used to lookup the SMPP message_id returned as this > information is not passed on bearerbox.) > > > - Yang Zhao > > >
