Re: Can an sms-service be configured to retry http delivery after failure to post a url ?

hi,

Stipe Tolj wrote:

> Peter Farmer wrote:
> 
>> Hi,
>> 
>> I have been scanning the user doco and reading the mail archives, but
>> havent been able to find an answer . I hope that someone on the list can
>> set me straight. We have set up kannel to channel MO SMS's to a 3rd
>> parties web application servers. Which works quite well. The target http
>> server has other users apart from our sms gateway, and we occassionally
>> have incoming messages blocked from being delivered because of connection
>> limits being reached on
>> the target.  Obviously there may be various other resource or operational
>> reasons why our attempts to transfer sms's to a system not under our
>> control
>> could  fail (in essence we get a 4xx, 5xx http status reply, or no
>> response at all) .
>> What we require to happen in this circumstance is not to send a delivery
>> report to the sending phone number reporting the failure , but for the
>> smsbox to queue the message and retry posting it a later date (i.e a
>> store & forward mechanism) and then just expire quietly after a
>> designated retry period. Is this possible with the existing kannel system
>> or am i up for some late night
>> coding to my own sms-box extensions  ?
>> There appears to be a qeueing facility for the reverse operation of
>> sending
>> sms's submitted to an smsbox via http.  So there is a message storing
>> mechanism that might be used . But I see no way to key into that based on
>> a http response code. The sms-box can handle http redirect responses
>> (30x) autonomously, so i have some hope that I could configure/extend
>> kannel to respond appropriately to other http request response code.
>> 
>> Thanks for your input in advance
> 
> now, we have "at least" an HTTP request retry mechanism inside of smsbox,
> that helps dealing with "HTTP server not available" issues. To have a
> persistant queue of MO messages that should get transported to the
> application layer you need store-file support inside smsbox. Which is not
> supported in the raw Kannel.
> 
> See 'http-request-retry' and 'http-queue-delay' config directives gor
> smsbox group.
> 
> @Alex, any intention from your side to put this on official cvs, or should
> we go ahead any addopt it from the private tree?

nope and IMO it's not needed. just don't send ack/nack to bearerbox as long
the message is not processed and bearerbox will do the job for free.

> 
> BTW, this brings again a more semantical question to the top. Should a
> "messaging node" try infinitly to deliver a message to the next node (the
> application layer in this case)? I don't think so. Actually it's the
> "fault" of the next node, if the HTTP server breaks and responds with HTTP
> 500. IMO, a node inside a communication path is not required to "cover"
> errors of the participating nodes. But I guess this is a "system
> architecture" religious question.

IMO if server responds then message processing is done, another story if
http server is not reachable, in this case smsbox should re-try depending
on 'http-request-retry' and 'http-queue-delay' config directives.


> 
> mailto:stolj_{at}_wapme.de
> -------------------------------------------------------------------
> Wapme Systems AG
> 
> Vogelsanger Weg 80
> 40470 DÃŒsseldorf, NRW, Germany
> 
> phone: +49.211.74845.0
> fax: +49.211.74845.299
> 
> mailto:info_{at}_wapme-systems.de
> http://www.wapme-systems.de/
> -------------------------------------------------------------------

-- 
Thanks,
Alex