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
