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?
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.
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/ -------------------------------------------------------------------
