Re: [PATCH] preliminary confirmed sendsms

+1 fo b) or c).
This will change the default behavior and may broke alot of
aplications that depend on the 202.
You should be allowed to configure kannel to have the same behavior.

</j>

On Wed, 06 Oct 2004 15:52:40 +0300, Kalle Marjola <[email protected]> wrote:
> This patch is the first version of sendsms confirmations.
> 
> This patch actually does what smsbox should have done like 4 years ago
> but I was too lazy to implement it back then because it is a bit
> complicated in logic. Later on I did that to NMGW, but as NMGW is
> single-process, it was simpler in that. But now it is, at last, here for
> original Kannel.
> 
> So, what does this first version do:
> Instead of immediately saying '202 Send' for valid sendsms request, this
> patch waits for bearerbox ACK before replying to HTTP client.
> Valid replies are based on msg.h and are now:
> 202 0: Accepted for delivery (routed to SMSC driver)
> 202 3: Queued for later delivery (all SMSCes currently down)
> 403 Forbidden (no SMSC comfigured to accept this, fix something)
> 503 Service unavailable (queue full or other problem. Try again later)
> 
> This is still far from ideal (to get SMSC reply), but better
> than earlier. And this is how it should have been, always,
> as why else these is those 'ack' type messages flying around...
> (currently they are just discarded)
> 
> Performance notes:
>  * yes, it takes a microsecond longer for Kannel to reply to
>    sendsms. Moreover, if system is completyl bogged down, HTTP
>    queries start to build up, too.
>  * if SMS is multisent (several receivers), status and reply
>    is based on first ACK from bearerbox, rest are discarded
> 
> This patch also includes one horrible kludge, which could be cleaned
> away...  (I also did not do documentation updates because this first
> needs approval etc.)
> 
> In addition, there is always the question how this should be used:
> a) always on
> b) used unless so configured   (fast-reply = true ??)
> c) used if so configured  (waited-reply = true ??)
> I didn't add config value for b/c, yet, as I strongly press that it
> should be a) :]  Those who are afraid of change should vote for b and c,
> but if c is selected, at least smskannel.conf should be updated to
> normally enable this... (I know that most Kannel installations use
> smskannel.conf as base for configuration - well at least most I have
> seen =)
> 
> And why should this be used:
>  * better knowledge what did happen
>  * better responses to bad configuration or SMSC problems
>  * messages cannot be lost if store-file on!
>    (earlier they could be lost before bearerbox could store them)
>  * allows later update to include 'confirmed-send = true' type
>    of service, i.e. wait for SMSC ack/nack before replying
> 
> PS: What happened to clean 'release all' code? I compiled with checking
> alloc and there always seems to be some memory not freed in end.
> Moreover, there seemed to be some leaks around...
> 
> --
>  &Kalle Marjola ::: Development ::: Helsinki ::: Enpocket
> 
>