Re: returning actual SMPP SMSC accept/deny status when using HTTP interface

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