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


Reply via email to