When using Kannel, one very common "problem" people have is that sendsms interface replies 'sent' even if it really does not mean anything else than 'your request seems to be correct, we will try to send it'. The optimal situation would be that if Kannel replies 'sent' it really means that, but as we all know, because of queues and multiple processes, that is far from trivial and in most cases, practical.
Yes, I know there is DLRs, but they are a) sometimes not supported, and b) much more complex in a way that Kannel does HTTP later on back to originator So, back in NMGW I made it that way that as a reply to sendsms request, the user received either 'accepted for delivery' or 'queued', but it was easier to do it as it used merged bearerbox and smsbox (same process) and thus sendsms interface directly called smsc2_rout(..). Moreover, still if the message was queued inside a SMSC driver that would be classified as 'acceped for delivery' - not a perfect, then, as what "users" want is a guarantee that the SMSC has accepted the message.. So, I was thinking how to implement this feature. I came up with following procedure: 1) get sendsms request, send it onward to bearerbox, but do not reply to HTTP client but instead go to sleep 2) in bearerbox, message is handled almost normally. When smsc driver returns a reply (the moment when the message would be removed from store-file), a message of operation status would be sent to smsbox.. 3) and when this reply arrives, original thread is awaken and the client gets its response So, this would mean that such a sendsms request would hang for a while (depending on SMSC speed, more if the system is slowed down or have problems). Thus this feature would be inpractical for mass sendings, as it would result in a) more traffic (reply messages to smsbox) and b) lots of open connections (resource usage), and so it should only be used if so desired, like sendsms?.... &wait-for-reply=1 (or as sendsms user, wait-for-reply = true). But it would be very useful for low-rate services. Any comments before I might start implementing this..? :] -- &Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
