+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 > >
