So if I understand you, we have two questions to answer. 1. Where to cascade to ? 2. Under what conditions should the cascade be triggered i.e defining the state "not working"?
One way to approach the first problem is to introduce a group which could be called "cascade-list". Where you list SMSCID's in the order which they should be cascaded. The second problem is really a question of how granular we choose to make the routing logic and like you rightly said that would ultimately impact performance. If we shift the focus from maintaining state on each MT to tracking the state of already available variables such as 1. MT Queue size on primary SMSCID. 2. Failure rate on primary SMSCID. e.t.c (this could be explored in some more detail) we may be able to achieve similar results without the downside of having to keep state on every single MT. Ehi Rancard Solutions Ltd. web: www.rancardsolutions.com email: [EMAIL PROTECTED] mobile: +233.27.622.1212 office: +233.21.782.949 -----Original Message----- From: Stipe Tolj [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 20, 2006 12:57 AM To: Kannel Development list Subject: [RFC] Enhanced cascading SMSC routing Hi list, Gottfried from Siemens ask me if Kannel is capable of acting in the way to "failback" to alternative routes (SMSC connections obviously) when the primary route is not "working". Of course we can do this for the case the SMSC is generally not available in the term that it is in the state offline or re-connecting. If we hard-wire a smsc group with allowed-smsc-id and address a MT to that smsc-id, and the connection is online, bearerbox picks that "queue" and drops it to the protocol module layer. After that we get either a ACK or NACK from the SMSC we interpret the MT as "Sent SMS" in access-log (hence success) or "FAILED SMS" (hence failure). Now, I'd like to throw some thoughts into list's space in how to handle cascading routing. What does this mean? This means re-routing decissions based on protocol specific ACK or (better) NACK states. Think of a SMPP server that responds with a negative submit_sm_resp PDU due to the fact that the destination MSISDN can't be reached, hence Kannel would know that that specific SMSC has been considered as "pimary" route, but fails and we consider a cascade of follow-up SMSCs to try. Obviously this would need re-consideration of our routing logic at bearerbox layer. We need state control and state management on each MT (which is impacting performance in some sense), etc. etc. Constructive thoughts on this please. (and not only: "yeah, we wanna have it, please code it. When is it gonna be available? Yesterday please." ;) Stipe ------------------------------------------------------------------- Kölner Landstrasse 419 40589 Düsseldorf, NRW, Germany tolj.org system architecture Kannel Software Foundation (KSF) http://www.tolj.org/ http://www.kannel.org/ mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org ------------------------------------------------------------------- -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.24/592 - Release Date: 12/18/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.24/592 - Release Date: 12/18/2006
