Re: sendsms and wait-for-reply

Hi Kalle,

why not just use dlr's with mask SMSC_[SUCCESS|FAILED] and handle these in
smsbox?

with following procedure:
1) sendsms request forward to bearerbox with no reply and dlr mask
SMSC_[SUCCESS|FAILED] set (store e.g. in dict: uuid + http client)
2) handle msg in bearerbox w/o any changes
3) if msg sent/failed you will get dlr for this and can forward status to
HTTP client (get http-client from dict for dlr uuid)

so we have no need to handle such specific thing in bearerbox and only
external entities must know about such procedure.

One thing that we should implement for this feature to work, is
store/forward of original uuid's in dlr's. I have already patch for this...

Kalle Marjola wrote:

> 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..? :]
> 
> 

-- 
Thanks,
Alex